Re: [Django] #30253: Add a note that `nulls_first` or `nulls_last` can be set in `order_by` using an F expression.

[Django]

#30253: Add a note that `nulls_first` or `nulls_last` can be set in `order_by`
using an F expression.
---+--
 Reporter:  Paul Wayper|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords:  documentation  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Paul Wayper):

 I've created this branch for a first draft of the documentation change:

 https://github.com/django/django/pull/11083

 Let me know what you think!

-- 
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.311fcbaf867c1ac997298a4460099f31%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30253: Add a note that `nulls_first` or `nulls_last` can be set in `order_by` using an F expression.

[Django]

#30253: Add a note that `nulls_first` or `nulls_last` can be set in `order_by`
using an F expression.
-+---
   Reporter:  Paul Wayper|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Documentation  |Version:  2.1
   Severity:  Normal |   Keywords:  documentation
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
 While the `nulls_first` and `nulls_last` are documented in the F
 expression documentation, this is not included in the documentation on the
 `order_by` queryset method.  It would be useful to include a note, and
 possibly and example, in the `order_by` method to make it easier to find.

-- 
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/050.4d991f79b173b5f15132bc6050d30d2f%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:  File |  Version:  2.1
  uploads/storage|
 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
-+-

Comment (by Tim Graham):

 Can you offer a test for Django's test suite that demonstrates the issue?
 Do you have a fix in mind?

-- 
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.0c18ad549f7f99cfbda2fef5467f2898%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Maciej Olko):

 * cc: Maciej Olko (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 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/062.bb65e861e268b901b474ab079865f031%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Flávio Juvenal):

 Thanks Tim, thread created on django-developers:
 https://groups.google.com/d/msg/django-developers/b_7XQYFaVeU/7M5KtGM2CAAJ

-- 
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/062.ad3c09a25e3778f4c960cbd836689908%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Flávio Juvenal:

Old description:

> There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
> issue] that prevents common flows (sequences of requests) to work
> properly if there's `SameSite=lax` on cookies. This issue was
> [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
> Bates, from Apple] and it's still open.
>
> Examples of broken flows:
> - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
> asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
> - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
> cookie-issue-with-safari-12/
> - Validating an email: https://bugs.webkit.org/show_bug.cgi?id=188165#c40
> - SAML flow: https://github.com/IronCountySchoolDistrict/django-
> python3-saml/issues/1
>
> Since Safari 12 is the current stable version and it's widely deployed on
> iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
> `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
> general solution and it's
> [https://github.com/aspnet/Announcements/issues/318 the one recommended
> by Microsoft to fix the similar issue on ASP.NET] (they didn't change the
> default, though).
>
> Core developers, could you please let me know if you agree with that
> change, so I can make a PR updating the defaults and the documentation?
>
> I think both CSRF and Session cookies shouldn't have the SameSite flag
> because I've found many 403 Forbidden issues on both on Safari 12. If
> more steps to reproduce beyond the links above are necessary, please let
> me know.

New description:

 There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
 issue] that prevents common flows (sequences of requests) to work properly
 if there's `SameSite=lax` on cookies. This issue was
 [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
 Bates, from Apple] and it's still open.

 Examples of broken flows:
 - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
 asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
 - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
 cookie-issue-with-safari-12/
 - Validating an email: https://bugs.webkit.org/show_bug.cgi?id=188165#c40
 - SAML flow: https://github.com/IronCountySchoolDistrict/django-
 python3-saml/issues/1

 Since Safari 12 is the current stable version and it's widely deployed on
 iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
 `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
 general solution and it's
 [https://github.com/aspnet/Announcements/issues/318 the one recommended by
 Microsoft to fix the similar issue on ASP.NET] (they didn't change the
 default, though).

 Core developers, could you please let me know if you agree with that
 change, so I can make a PR updating the defaults and the documentation?

 I think both CSRF and Session cookies shouldn't have the SameSite flag
 because I've found many 403 Forbidden issues on both on Safari 12. If more
 steps to reproduce beyond the links above are necessary, please let me
 know.

 ---
 Update:

 In fact, a much simpler flow is broken on Safari 12 with the default "Lax"
 settings.
 If the user comes from a cross-site redirection (like a tracker link from
 an email provider), Safari doesn't send samesite=lax cookies on the
 request. This causes multiple issues:
 1. User will not be logged in if `SESSION_COOKIE_SAMESITE = 'Lax'`. That
 behavior is only expected if `'Strict'`.
 2. User will not be able to make AJAX POST requests if
 `CSRF_COOKIE_SAMESITE = 'Lax'`, because JS code won't be able to read the
 CSRF cookie.
 3. POSTs on other open tabs/windows will fail if `CSRF_COOKIE_SAMESITE =
 'Lax'`, because Safari triggered a CSRF cookie update after the first
 request without cookies.

 Those issues do not happen on Chrome.
 Full example here: https://github.com/vintasoftware/safari-samesite-
 cookie-issue

--

-- 
Ticket URL: 
Django 
The Web framework 

[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:  File uploads/storage  |Version:  2.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 |
+
 In django.forms.fields.ImageField's `to_python()` method, an uploaded
 image is validated by `open()`ing a PIL.Image object from it and calling
 `verify()` on that. Afterwards, the Image object is saved to an `image`
 attribute of the uploaded file (i.e. an InMemoryUploadedFile). According
 to a comment in the source, this happens so that "subclasses can reuse it
 for their own validation".

 Pillow closes an Image after `verify()`ing and the docs
 
[https://pillow.readthedocs.io/en/stable/reference/Image.html#PIL.Image.Image.verify
 state] that it cannot be used after calling `verify` on it:

   If you need to load the image after using this method, you must reopen
 the image file.

 For me, this resulted in the following error when trying to explicitly
 call `save()` on the Image, but similar effects will probably happen for
 any operation:

 {{{
   File ".../lib/python3.6/site-packages/PIL/Image.py", line 1960, in save
 self.load()
   File ".../lib/python3.6/site-packages/PIL/ImageFile.py", line 165, in
 load
 seek = self.fp.seek
 AttributeError: 'NoneType' object has no attribute 'seek'
 }}}

 This could be related to #13750, but I don't think so.

-- 
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/046.c1e703af36314f01f3bfbcba5ba850de%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30251: Include User Registration, Forgot password, Email link for Forgot password, OTP authentication by default

[Django]

#30251: Include User Registration, Forgot password, Email link for Forgot 
password,
OTP authentication by default
--+--
 Reporter:  parrocks  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  2.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

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


Comment:

 This ticket isn't actionable. Django already includes some of these
 features. Please  make a concrete proposal on the DevelopersMailingList.

-- 
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/066.d4fb9a18e3bc07b410bf37898c46fcf1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30251: Include User Registration, Forgot password, Email link for Forgot password, OTP authentication by default

[Django]

#30251: Include User Registration, Forgot password, Email link for Forgot 
password,
OTP authentication by default
--+--
 Reporter:  parrocks  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  2.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 parrocks):

 * type:  Uncategorized => New 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/066.a43eee6f644978dccd49be77a948c52d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30251: Include User Registration, Forgot password, Email link for Forgot password, OTP authentication by default

[Django]

#30251: Include User Registration, Forgot password, Email link for Forgot 
password,
OTP authentication by default
---+--
 Reporter:  parrocks   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Other)   |  Version:  2.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
---+--
Description changed by parrocks:

Old description:

> Please include an easy to set up option for the following features:
>
> {{{
> User Registration
> Forgot password
> Email link for Forgot password
> OTP authentication
> }}}
>
> Those features would make Django one of the most easy to use for building
> small web apps.
> Please definitely consider having them natively within Django as a
> default one.

New description:

 Please include an easy to set up option for the following features:

 {{{
 User Registration
 Forgot password
 Email link for Forgot password
 OTP authentication
 }}}

 Those features would make Django one of the most easy to use framework for
 building secure web apps.
 Please definitely consider having them natively within Django as a default
 one.

--

-- 
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/066.67399361856e9d247f1e0b7b2feb965a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30251: Include User Registration, Forgot password, Email link for Forgot password, OTP authentication by default

[Django]

#30251: Include User Registration, Forgot password, Email link for Forgot 
password,
OTP authentication by default
-+
   Reporter:  slithers   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Core (Other)   |Version:  2.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  |
-+
 Please include an easy to set up option for the following features:

 {{{
 User Registration
 Forgot password
 Email link for Forgot password
 OTP authentication
 }}}

 Those features would make Django one of the most easy to use for building
 small web apps.
 Please definitely consider having them natively within Django as a default
 one.

-- 
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/051.d58715d78b153b64e7d5f0a0050b7c3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Core (Other)
 * easy:  1 => 0
 * stage:  Unreviewed => Someday/Maybe


Comment:

 Please raise the issue on the DevelopersMailingList as it gets more
 attention than this ticket tracker.

-- 
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/062.39ebee0c756270e0b7978bb7e51a3eea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30183: SQLite instrospection.get_constraints() for unique constraints return wrong count of constraints and doesn't have columns for all items

[Django]

#30183: SQLite instrospection.get_constraints() for unique constraints return 
wrong
count of constraints and doesn't have columns for all items
-+-
 Reporter:  Pavel Tyslacki   |Owner:  Pavel
 |  Tyslacki
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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 Tim Graham ):

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


Comment:

 In [changeset:"782d85b6dfa191e67c0f1d572641d8236c79174c" 782d85b]:
 {{{
 #!CommitTicketReference repository=""
 revision="782d85b6dfa191e67c0f1d572641d8236c79174c"
 Fixed #30183 -- Added introspection of inline SQLite constraints.
 }}}

-- 
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.bd989b6c4bb46b5232fb4243b5f222d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Flávio Juvenal:

Old description:

> There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
> issue] that prevents common flows (sequences of requests) to work
> properly if there's `SameSite=lax` on cookies. This issue was
> [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
> Bates, from Apple] and it's still open.
>
> Examples of broken flows:
> - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
> asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
> - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
> cookie-issue-with-safari-12/
> - Clicking a link on an email:
> https://bugs.webkit.org/show_bug.cgi?id=188165#c40
> - SAML flow: https://github.com/IronCountySchoolDistrict/django-
> python3-saml/issues/1
>
> Since Safari 12 is the current stable version and it's widely deployed on
> iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
> `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
> general solution and it's
> [https://github.com/aspnet/Announcements/issues/318 the one recommended
> by Microsoft to fix the similar issue on ASP.NET] (they didn't change the
> default, though).
>
> Core developers, could you please let me know if you agree with that
> change, so I can make a PR updating the defaults and the documentation?
>
> I think both CSRF and Session cookies shouldn't have the SameSite flag
> because I've found many 403 Forbidden issues on both on Safari 12. If
> more steps to reproduce beyond the links above are necessary, please let
> me know.

New description:

 There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
 issue] that prevents common flows (sequences of requests) to work properly
 if there's `SameSite=lax` on cookies. This issue was
 [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
 Bates, from Apple] and it's still open.

 Examples of broken flows:
 - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
 asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
 - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
 cookie-issue-with-safari-12/
 - Validating an email: https://bugs.webkit.org/show_bug.cgi?id=188165#c40
 - SAML flow: https://github.com/IronCountySchoolDistrict/django-
 python3-saml/issues/1

 Since Safari 12 is the current stable version and it's widely deployed on
 iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
 `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
 general solution and it's
 [https://github.com/aspnet/Announcements/issues/318 the one recommended by
 Microsoft to fix the similar issue on ASP.NET] (they didn't change the
 default, though).

 Core developers, could you please let me know if you agree with that
 change, so I can make a PR updating the defaults and the documentation?

 I think both CSRF and Session cookies shouldn't have the SameSite flag
 because I've found many 403 Forbidden issues on both on Safari 12. If more
 steps to reproduce beyond the links above are necessary, please let me
 know.

--

-- 
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/062.a64649e6ee863592fcd8353ba5ba04b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Flávio Juvenal:

Old description:

> There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
> issue] that prevents common flows (sequences of requests) to work
> properly if there's `SameSite=lax` on cookies. This issue was
> [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
> Bates, from Apple] and it's still open.
>
> Examples of broken flows:
> - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
> asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
> - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
> cookie-issue-with-safari-12/
> - Clicking a link on an email:
> https://bugs.webkit.org/show_bug.cgi?id=188165#c40
> - SAML flow: https://github.com/IronCountySchoolDistrict/django-
> python3-saml/issues/1
>
> Since Safari 12 is the current stable version and it's widely deployed on
> iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
> `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
> general solution and it's
> [https://github.com/aspnet/Announcements/issues/318 the one recommended
> by Microsoft to fix the similar issue on ASP.NET].
>
> Core developers, could you please let me know if you agree with that
> change, so I can make a PR updating the defaults and the documentation?
>
> I think both CSRF and Session cookies shouldn't have the SameSite flag
> because I've found many 403 Forbidden issues on both on Safari 12. If
> more steps to reproduce beyond the links above are necessary, please let
> me know.

New description:

 There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
 issue] that prevents common flows (sequences of requests) to work properly
 if there's `SameSite=lax` on cookies. This issue was
 [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
 Bates, from Apple] and it's still open.

 Examples of broken flows:
 - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
 asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
 - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
 cookie-issue-with-safari-12/
 - Clicking a link on an email:
 https://bugs.webkit.org/show_bug.cgi?id=188165#c40
 - SAML flow: https://github.com/IronCountySchoolDistrict/django-
 python3-saml/issues/1

 Since Safari 12 is the current stable version and it's widely deployed on
 iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
 `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
 general solution and it's
 [https://github.com/aspnet/Announcements/issues/318 the one recommended by
 Microsoft to fix the similar issue on ASP.NET] (they didn't change the
 default, though).

 Core developers, could you please let me know if you agree with that
 change, so I can make a PR updating the defaults and the documentation?

 I think both CSRF and Session cookies shouldn't have the SameSite flag
 because I've found many 403 Forbidden issues on both on Safari 12. If more
 steps to reproduce beyond the links above are necessary, please let me
 know.

--

-- 
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/062.17ce5e6f39c4277530822baf5984fff2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Flávio Juvenal:

Old description:

> There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
> issue] that prevents common flows (sequences of requests) to work
> properly if there's `SameSite=lax` on cookies. This issue was
> [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
> Bates, from Apple] and it's still open.
>
> Examples of broken flows:
> - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
> asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
> - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
> cookie-issue-with-safari-12/
> - Clicking a link on an email:
> https://bugs.webkit.org/show_bug.cgi?id=188165#c40
> - SAML flow: https://github.com/IronCountySchoolDistrict/django-
> python3-saml/issues/1
>
> Since Safari 12 is the current stable version and it's widely deployed on
> iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
> `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the more
> general solution and it's
> [https://github.com/aspnet/Announcements/issues/318 the one recommended
> by Microsoft to fix the similar issue on ASP.NET].
>
> Core developers, could you please let me know if you agree with that
> change, so I can make a PR updating the defaults and the documentation?
>
> I think both CSRF and Session cookies shouldn't have the SameSite flag
> because I've found many 403 Forbidden issues on both on Safari 12. If
> more steps to reproduce beyond the links above are necessary, please let
> me know.

New description:

 There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
 issue] that prevents common flows (sequences of requests) to work properly
 if there's `SameSite=lax` on cookies. This issue was
 [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
 Bates, from Apple] and it's still open.

 Examples of broken flows:
 - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
 asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
 - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
 cookie-issue-with-safari-12/
 - Clicking a link on an email:
 https://bugs.webkit.org/show_bug.cgi?id=188165#c40
 - SAML flow: https://github.com/IronCountySchoolDistrict/django-
 python3-saml/issues/1

 Since Safari 12 is the current stable version and it's widely deployed on
 iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
 `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the most
 general solution and it's
 [https://github.com/aspnet/Announcements/issues/318 the one recommended by
 Microsoft to fix the similar issue on ASP.NET].

 Core developers, could you please let me know if you agree with that
 change, so I can make a PR updating the defaults and the documentation?

 I think both CSRF and Session cookies shouldn't have the SameSite flag
 because I've found many 403 Forbidden issues on both on Safari 12. If more
 steps to reproduce beyond the links above are necessary, please let me
 know.

--

-- 
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/062.71452dfd91d2084c1d408b8f2b65f79f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
 Reporter:  Flávio Juvenal   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  samesite,csrf,session,cookies  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Flávio Juvenal:

Old description:

> There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
> issue] that prevents common flows (sequences of requests) to work
> properly if there's `SameSite=lax` on cookies. This issue was
> [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
> Bates, from Apple] and it's still open.
>
> Examples of broken flows:
> - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
> asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
> - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
> cookie-issue-with-safari-12/
> - Clicking a link on an email:
> https://bugs.webkit.org/show_bug.cgi?id=188165#c40
> - SAML flow: https://github.com/IronCountySchoolDistrict/django-
> python3-saml/issues/1
>
> Since Safari 12 is the current stable version and it's widely deployed on
> iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
> `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`.
>
> Core developers, could you please let me know if you agree with that
> change, so I can make a PR updating the defaults and the documentation?
>
> I think both CSRF and Session cookies shouldn't have the SameSite flag
> because I've found many 403 Forbidden issues on both on Safari 12. If
> more steps to reproduce beyond the links above are necessary, please let
> me know.

New description:

 There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
 issue] that prevents common flows (sequences of requests) to work properly
 if there's `SameSite=lax` on cookies. This issue was
 [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
 Bates, from Apple] and it's still open.

 Examples of broken flows:
 - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
 asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
 - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
 cookie-issue-with-safari-12/
 - Clicking a link on an email:
 https://bugs.webkit.org/show_bug.cgi?id=188165#c40
 - SAML flow: https://github.com/IronCountySchoolDistrict/django-
 python3-saml/issues/1

 Since Safari 12 is the current stable version and it's widely deployed on
 iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
 `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`. That's the more
 general solution and it's
 [https://github.com/aspnet/Announcements/issues/318 the one recommended by
 Microsoft to fix the similar issue on ASP.NET].

 Core developers, could you please let me know if you agree with that
 change, so I can make a PR updating the defaults and the documentation?

 I think both CSRF and Session cookies shouldn't have the SameSite flag
 because I've found many 403 Forbidden issues on both on Safari 12. If more
 steps to reproduce beyond the links above are necessary, please let me
 know.

--

-- 
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/062.c61b85799948e3cde8303fd09a148ac5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies should NOT be Lax by default

[Django]

#30250: Due to iOS Safari 12 issue, SameSite flag on session and CSRF cookies
should NOT be Lax by default
-+-
   Reporter:  Flávio |  Owner:  nobody
  Juvenal|
   Type:  Bug| Status:  new
  Component: |Version:  2.1
  Uncategorized  |   Keywords:
   Severity:  Normal |  samesite,csrf,session,cookies
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 There's a [https://bugs.webkit.org/show_bug.cgi?id=188165 iOS Safari 12
 issue] that prevents common flows (sequences of requests) to work properly
 if there's `SameSite=lax` on cookies. This issue was
 [https://bugs.webkit.org/show_bug.cgi?id=188165#c27 confirmed by Daniel
 Bates, from Apple] and it's still open.

 Examples of broken flows:
 - OpenIdConnect: https://community.auth0.com/t/authentication-broken-on-
 asp-net-core-and-safari-on-ios-12-mojave-take-2/19104
 - Shopify app OAuth flow: https://www.calazan.com/django-21-samesite-
 cookie-issue-with-safari-12/
 - Clicking a link on an email:
 https://bugs.webkit.org/show_bug.cgi?id=188165#c40
 - SAML flow: https://github.com/IronCountySchoolDistrict/django-
 python3-saml/issues/1

 Since Safari 12 is the current stable version and it's widely deployed on
 iOS devices, I believe the Django default for `CSRF_COOKIE_SAMESITE` and
 `SESSION_COOKIE_SAMESITE` should be `None`, not `Lax`.

 Core developers, could you please let me know if you agree with that
 change, so I can make a PR updating the defaults and the documentation?

 I think both CSRF and Session cookies shouldn't have the SameSite flag
 because I've found many 403 Forbidden issues on both on Safari 12. If more
 steps to reproduce beyond the links above are necessary, please let me
 know.

-- 
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/047.621c31832fa37a6ece5b2a640ba40c09%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29810: Left outer join using FilteredRelation failed on empty result

[Django]

#29810: Left outer join using FilteredRelation failed on empty result
-+-
 Reporter:  Dmitrii Azarenko |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM  | Triage Stage:  Accepted
  FilteredRelation   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Can Sarıgöl):

 Sorry, I didn't think it was about PR. I'm looking at

-- 
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.823479f5581b7868d537ce319678cfa4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30199: get_or_create documentation encourages unsafe usage

[Django]

#30199: get_or_create documentation encourages unsafe usage
--+
 Reporter:  Alex  |Owner:  Alex
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  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


Comment:

 As per [https://github.com/django/django/pull/11017#issuecomment-472440933
 comment on PR] there's Tim's point to be addressed, and I think probably a
 move of this discussion to `docs/ref/databases.txt` where the MySQL
 isolation level is discussed, since Django's default behaviour is by-and-
 large correct since 924af638e4d4fb8eb46a19ac0cafcb2e83480cf3, which was
 part of #27683.

-- 
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.3750daadadc68e30cfd04a4f9dfad333%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29810: Left outer join using FilteredRelation failed on empty result

[Django]

#29810: Left outer join using FilteredRelation failed on empty result
-+-
 Reporter:  Dmitrii Azarenko |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM  | Triage Stage:  Accepted
  FilteredRelation   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 Tests aren't passing.

-- 
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.e347faa9b2d6a21d9318eff983309695%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30248: Implement case insensitive fields in Sqlite

[Django]

#30248: Implement case insensitive fields in Sqlite
-+-
 Reporter:  Stuart Axon  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  sqlite citext| Triage Stage:
  postgres   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Sqlite supports case insensitive fields by setting COLLATE NOCASE.
>
> This works as you would expect for SELECT and INSERT.
>

> It would be great to have equivalents to the CIText fields in
> postgres.contrib - this would make it a lot easier to unit test code
> using those fields.

New description:



--

Comment (by Stuart Axon):

 Cheers, I did send an initial mail to the dev list, but think it might
 have got eaten as I didn't see it (also had a bit of bad luck updating
 this ticket, updating the description, not leaving a comment).

 One thing I found out, is that even with COLLATE NOCASE sqlites regexes
 don't default to case insensitive, so that would need some support at the
 django end.

 I had a bit of a look into how the postgres citext works, but couldn't
 work out how to make Operators that integrate with Django in the same way.
 I guess a really tiny implementation, as fields.py might be a start ?

-- 
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.9b5258eb4846bd6e6cc9a6350c411295%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30249: Deprecate re-raising view exceptions from test client in tests

[Django]

#30249: Deprecate re-raising view exceptions from test client in tests
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hey Jon.

 Thanks for the follow-up.

 Quick comments:

 1. Some helper would be better yes. `assertResponseException()` or such.
 2. The issue with the setting isn't that you invented it or not: rather
 it's using a setting, which has other purposes, to control the test-client
 behaviour.

 I like and use the current behaviour. Maybe one-day we remove
 `DEBUG_PROPOGATE_EXCEPTION`, for a custom `handler` subclass or such. What
 do I do then? (For me ) clearly the right answer is a flag on
 `TestClient`, which we already have.

 (**Maybe** then swapping the default...? — but ''meh''... g...)

 (Re, the churn, yes, if we think it's an improvement then the churn is
 worth it — I'm just not there as yet.)

-- 
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.b9f2211a1c526a7f9075108c2178e200%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30249: Deprecate re-raising view exceptions from test client in tests

[Django]

#30249: Deprecate re-raising view exceptions from test client in tests
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne):

 Hi Carlton, thanks for the response.

 > It's both longer ...

 If you feel this is a matter of ergonomics, then I'm happy to add a helper
 assert method. Something this like `assertResponseException` such that

 {{{
 response = self.client.get('/detail/author/invalid/qs/')
 self.assertEqual(response.status_code, 500)
 _, exc_value, _ = response.exc_info
 self.assertIsInstance(exc_value, ImproperlyConfigured)
 self.assertEqual(str(exc_value), msg)
 }}}

 Becomes:

 {{{
 response = self.client.get('/detail/author/invalid/qs/')
 self.assertResponseException(response, response, msg)
 }}}

 I could then document it and use it throughout the Django test suite.
 WDYT?

 > ... and less clear in intent.

 IMO, the previous version is less clear of the ''actual behavior'' under
 test. If I didn't already know how the Django test client works, when
 reading:

 {{{
 with self.assertRaisesMessage(ImproperlyConfigured, msg):
 self.client.get('/detail/author/invalid/qs/')
 }}}

 Upon first read (again, if I didn't already know how the Django test
 client works) this leads me to believe that making a GET request on the
 provided URL results in an '''unhandled''' exception. However, this is not
 the case. The exception is handled by the default error handler,
 `django.core.handlers.exception.handle_uncaught_exception` and a 500
 response is returned. Obviously, this is wrong as the test client has
 modified the code under test to make it appear as if the exception is
 unhandled. IMO, it is normally bad practice to modify the code under test
 unless testing for a very specific implementation detail. It should not be
 the default state of testing. Instead, we should be testing code as close
 to production as reasonable. By modifying the code under test, we've
 slightly moved away from the production code.

 > Raising the exception is a great behaviour in most cases. It's a great
 default behaviour.

 Normally, I agree. But keep in mind, we're in the context of a test.
 ''Something'' will be asserted after the middleware + view executes
 (otherwise, what's the point of the test?) It could even be something as
 simple as `self.assertEqual(response.status_code, 200)`. In the event of
 an unwanted view exception, these assertions will fail.

 If you prefer the re-raising of exceptions for your project, then you can
 and should set the existing setting `DEBUG_PROPAGATE_EXCEPTIONS` to `True`
 in the test's `settings.py`. Then, the old behavior will be restored to
 eagerly throw exceptions.

 I've created an alternate form of the PR with this set during Django's
 test suite here:

 https://github.com/django/django/compare/master...jdufresne:raise-request-
 exception-default-on

 As you can see, this version has many fewer adjustments to tests. If this
 version is more agreeable, I'm happy to replace the PR with it.

 > The @override_settings(DEBUG_PROPAGATE_EXCEPTIONS=False) is bad API.

 This setting already exits. I didn't invent it. It is documented here:
 https://docs.djangoproject.com/en/2.1/ref/settings/#debug-propagate-
 exceptions

 I don't care much for this setting on its own, I only noticed that it
 already existed so I didn't invent a new mechanism. Having multiple ways
 to re-raise request exceptions seems unnecessary to me. I've never used it
 prior to this PR.

 > Beyond all that I don't think it's worth the churn.

 To be clear, this isn't about churn. It is about moving the test client
 closer to simulating a real world HTTP client by avoiding modifying code
 under test, which I believe will result in more productive tests.

-- 
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 

Re: [Django] #29810: Left outer join using FilteredRelation failed on empty result

[Django]

#29810: Left outer join using FilteredRelation failed on empty result
-+-
 Reporter:  Dmitrii Azarenko |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM  | Triage Stage:  Accepted
  FilteredRelation   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * cc: Can Sarıgöl (added)
 * 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 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.a24fd37d480f499c2e16dd5b1d4c12f7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29810: Left outer join using FilteredRelation failed on empty result

[Django]

#29810: Left outer join using FilteredRelation failed on empty result
-+-
 Reporter:  Dmitrii Azarenko |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM  | Triage Stage:  Accepted
  FilteredRelation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Can Sarıgöl):

 Hi, could you review this [https://code.djangoproject.com/ticket/29810
 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/064.38cfec720ada577bd233d65d538b385c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30064: Admin search with a null character crashes with "A string literal cannot contain NUL (0x00) characters." on PostgreSQL

[Django]

#30064: Admin search with a null character crashes with "A string literal cannot
contain NUL (0x00) characters." on PostgreSQL
---+---
 Reporter:  kenichi-cc |Owner:  Can Sarıgöl
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.1
 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


Comment:

 Unrelated changes need moving to separate cleanup ticket/PR, but looking
 good after that.

-- 
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.86c50f82b33c1aee41bde86ba63b0772%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5793: Allow custom attributes in Meta classes

[Django]

#5793: Allow custom attributes in Meta classes
-+-
 Reporter:  eikke@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlos Palol):

 * cc: Carlos Palol (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 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/073.19107bc2da2ce2e2fb6873dc90d4b0be%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30248: Implement case insensitive fields in Sqlite

[Django]

#30248: Implement case insensitive fields in Sqlite
-+-
 Reporter:  Stuart Axon  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  sqlite citext| Triage Stage:
  postgres   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hey Nick.

 > If this is possible...

 Oh, good idea.

 If someone wants to tell me that this is on, happy to see this moved into
 the Accepted pile.

 (Not sure what thoughts on a `contrib.sqlite` would be if not... —
 probably leaning towards third-party I'd guess.)

-- 
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.e2bf1fbdf50c15145d1d4bcfbe43c8c1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30249: Deprecate re-raising view exceptions from test client in tests

[Django]

#30249: Deprecate re-raising view exceptions from test client in tests
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Ah, grrr. I'd rather not. (As much as I was and am +1 on #18707.)

 Adjust below with "For me" whenever appropriate.

 Taking an arbitrary change from the PR:

 From this:

 {{{
 with self.assertRaisesMessage(ImproperlyConfigured, msg):
 self.client.get('/detail/author/invalid/qs/')
 }}}

 To this:

 {{{
 response = self.client.get('/detail/author/invalid/qs/')
 self.assertEqual(response.status_code, 500)
 _, exc_value, _ = response.exc_info
 self.assertIsInstance(exc_value, ImproperlyConfigured)
 self.assertEqual(str(exc_value), msg)
 }}}

 It's both longer and less clear in intent.

 Raising the exception is a great behaviour in most cases. It's a great
 default behaviour.
 Yes, it's nice to have a switch (which we now do) for testing error views.
 But the overall change isn't a win.

 The `@override_settings(DEBUG_PROPAGATE_EXCEPTIONS=False)` is bad API.
 I'm adjusting a setting to alter test client behaviour.
 I **want** a kwarg for that.

 Beyond all that I don't think it's worth the churn.

 Again, all "For me" where needed.

 As I say, grrr. -1 I'm afraid.

 I'll leave this open for now to allow others to comment, before the
 inevitable trip to the mailing list, but say wontfix here.
 (Sorry to think that.)

-- 
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.08d1524cfa62a6d4f03e61e784cced74%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.