Re: [Django] #30768: django.forms.boundfield.as_widget method hasn't been updated, and causes an exception when used!

2019-09-09 Thread Django
#30768: django.forms.boundfield.as_widget method hasn't been updated, and 
causes an
exception when used!
-+-
 Reporter:  Mark |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  boundfiled renderer  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Mark:

Old description:

> /django/forms/boundfield.py;90-95 calls widget.render() with
> 'rederer=self.form.renderer' on line 94
>
> the renderer argument was removed in 2.1;
>  in-2-1>
>
> This should be very easy to fix; it looks like this method wasn't updated
> when the renderer argument was removed.
>
> I commented out line 94 locally and it fixes the problem.
>
> I just installed 2.2.5 to verify that this still existed, I also did a
> search of existing tickets, but couldn't find this reported yet.

New description:

 /django/forms/boundfield.py;90-95 calls widget.render() with
 'rederer=self.form.renderer' on line 94

 the renderer argument was removed in 2.1;
 

 This should be very easy to fix; it looks like this method wasn't updated
 when the renderer argument was removed.

 I commented out line 94 locally and it fixes the problem.

 I just installed 2.2.5 to verify that this still existed, I also did a
 search of existing tickets, but couldn't find this reported yet.

 edit: I just rechecked the patch submission guidlines, and I made the
 patch wrong, its just the output of 'diff boundfield.py oldboundfield.py';
 its simply deleting line 94

--

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

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


Re: [Django] #30768: django.forms.boundfield.as_widget method hasn't been updated, and causes an exception when used!

2019-09-09 Thread Django
#30768: django.forms.boundfield.as_widget method hasn't been updated, and 
causes an
exception when used!
-+-
 Reporter:  chefables-mark   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  boundfiled renderer  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by chefables-mark):

 * Attachment "boundfield.py.diff" 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/072.212c3f71f2db4022a116db03467ff2b0%40djangoproject.com.


[Django] #30768: django.forms.boundfield.as_widget method hasn't been updated, and causes an exception when used!

2019-09-09 Thread Django
#30768: django.forms.boundfield.as_widget method hasn't been updated, and 
causes an
exception when used!
-+-
   Reporter: |  Owner:  nobody
  chefables-mark |
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  2.2
   Severity:  Normal |   Keywords:  boundfiled renderer
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 /django/forms/boundfield.py;90-95 calls widget.render() with
 'rederer=self.form.renderer' on line 94

 the renderer argument was removed in 2.1;
 

 This should be very easy to fix; it looks like this method wasn't updated
 when the renderer argument was removed.

 I commented out line 94 locally and it fixes the problem.

 I just installed 2.2.5 to verify that this still existed, I also did a
 search of existing tickets, but couldn't find this reported 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.70bf9d37540510d60b8e032c67e1a55f%40djangoproject.com.


Re: [Django] #28699: Document that REMOTE_USER must be logged in before making CSRF protected requests.

2019-09-09 Thread Django
#28699: Document that REMOTE_USER must be logged in before making CSRF protected
requests.
---+
 Reporter:  stephanm   |Owner:  Rodrigo
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  remote user| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Rodrigo):

 Replying to [comment:22 Carlton Gibson]:
 > > For this ticket I think documenting that remote user auth will require
 two requests — one to login, on to submit further data passing CSRF — is
 the best we can do.
 >
 > Actually, I'm not exactly sure what to say here. Thinking about it,
 exactly the same considerations apply to all login. You'd have to take
 special measures to login a user and submit additional form data, whilst
 also checking CSRF, in a single request, even if you were using session
 based authentication with the model backend. (You'd write a view to do it,
 manually calling `login()` yourself...)
 >
 > I'm kind of inclined towards `wontfix` for that reason...

 I am not sure if I am understanding, there will be always one extra
 request for getting the CSRF token before POSTing anything. The
 rotate_token() is called only by login(),  the RemoteUserMiddleware calls
 it only when user is not auth'ed (otherwise it just return) - which as you
 said before, it will be negated later by CSRF.process_view().

 If this would have worked as expected, the documentation should say
 something like "After a login, the client needs to update the CSRF one
 more time to keep posting in further requests - you may return it in your
 login view to save one request", which applies to all logins - as you
 said.

 In this case, as it is overridden, there is no need, because the view
 would be executed anyway and the data procesed - though without the
 rotate_token() protection.

 A fix for this that comes into my mind would be a "hook" on login to
 deffer the token rotation and set a "user_has_logged" flag if REMOTE_USER
 is enabled and then catch it later - as you said - to trigger the
 rotation. This way it would behave as other backends.

 Otherwise, it should be documented that token rotation on login is not
 functioning for the REMOTE_USER backend, so beware! :)

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

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


Re: [Django] #28107: Can't perform annotation on related table when un-managed model is backed by a DB view

2019-09-09 Thread Django
#28107: Can't perform annotation on related table when un-managed model is 
backed
by a DB view
-+-
 Reporter:  powderflask  |Owner:  Vojtěch
 |  Boček
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  QuerySet.extra   | 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:"b1d37fea8fd7904c2b2d11c91393cf1b989314b6" b1d37fe]:
 {{{
 #!CommitTicketReference repository=""
 revision="b1d37fea8fd7904c2b2d11c91393cf1b989314b6"
 Fixed #28107 -- Added
 DatabaseFeatures.allows_group_by_selected_pks_on_model() to allow enabling
 optimization for unmanaged models.
 }}}

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

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


Re: [Django] #28107: Can't perform annotation on related table when un-managed model is backed by a DB view

2019-09-09 Thread Django
#28107: Can't perform annotation on related table when un-managed model is 
backed
by a DB view
-+-
 Reporter:  powderflask  |Owner:  Vojtěch
 |  Boček
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | 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:"10d5e439e92da3881f5c32151f3a89f264c9cfd8" 10d5e43]:
 {{{
 #!CommitTicketReference repository=""
 revision="10d5e439e92da3881f5c32151f3a89f264c9cfd8"
 Refs #28107 -- Doc'd how to subclass an existing database 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/069.a2c9e080bb3f5adae8f410811999edbe%40djangoproject.com.


Re: [Django] #28107: Can't perform annotation on related table when un-managed model is backed by a DB view

2019-09-09 Thread Django
#28107: Can't perform annotation on related table when un-managed model is 
backed
by a DB view
-+-
 Reporter:  powderflask  |Owner:  Vojtěch
 |  Boček
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_docs:  1 => 0
 * 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/069.498bc0ac3d24bcdfa161b348e8ee56bc%40djangoproject.com.


Re: [Django] #30426: Make security headers default.

2019-09-09 Thread Django
#30426: Make security headers default.
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"1edbb6c19405a629200ba3683968f3dba2744e7e" 1edbb6c1]:
 {{{
 #!CommitTicketReference repository=""
 revision="1edbb6c19405a629200ba3683968f3dba2744e7e"
 Refs #30426 -- Moved release notes into separate security section.
 }}}

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

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


Re: [Django] #29406: Add Referrer-Policy header support

2019-09-09 Thread Django
#29406: Add Referrer-Policy header support
-+-
 Reporter:  James Bennett|Owner:  James
 |  Bennett
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"406dba04e1482a308cad74e3d06c050c76ba2d16" 406dba04]:
 {{{
 #!CommitTicketReference repository=""
 revision="406dba04e1482a308cad74e3d06c050c76ba2d16"
 Fixed #29406 -- Added support for Referrer-Policy header.

 Thanks to James Bennett for the initial implementation.
 }}}

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

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


Re: [Django] #30511: Support Identity columns on PostgreSQL.

2019-09-09 Thread Django
#30511: Support Identity columns on PostgreSQL.
-+-
 Reporter:  Michael Kany |Owner:  Michael
 |  Kany
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres generated   | Triage Stage:  Accepted
  identity   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by nbngn):

 Hi, I am also interested in having IDENTITY as Autofield in PostgreSQL. I
 have attempted to implement it the past few weeks according to the
 specifications mentioned here but it's not so easy.

 1. I was only able to write an exception for checking if the PostgreSQL
 version is >=10. I built it like the check if brin_autosummarize is
 allowed. Which is I will push once I have the rest of code with IDENTITY
 implemented (which will take a while). **What are the requirements to drop
 support for PostgreSQL < 10?**

 Built similarly to:
 
[https://github.com/django/django/blob/7254f1138d9c51fa558229c39c9559b369c4278a/django/db/backends/postgresql/features.py#L68
 has_brin_autosummarize in db\backends\postgresql\features.py]
 
[https://github.com/django/django/blob/85ac838d9e6975130b5c55299e9d7d1222a8e289/django/contrib/postgres/indexes.py#L57
 check_support has_brin_autosummarize in contrib\postgres\indexes.py]


 {{{
 #!python
 # in db\backends\postgresql\base.py:
 def check_supported(self):
 """
 Using IDENTITY is supported in since Django 3.0, PostgreSQL>=10.
 Using SERIAL is supported in Django Version<3.0, PostgreSQL<10.
 """
 if not self.features_class.changed_serial_to_identity:
 raise NotSupportedError('AutoField requires PostgreSQL 10+.
 Using SERIAL is supported in Django Version<3.0.')


 # in db\backends\postgresql\features.py:
changed_serial_to_identity =
 property(operator.attrgetter('is_postgresql_10'))


 # in tests\backends\postgresql\tests.py
 def test_database_supported_version(self):
 """
 Fundamental changes in AutoField requires PostgreSQL 10+.
 SQL-compliant GENERATED BY IDENTITY is supported instead of
 SERIAL.
 """
 from django.db.backends.postgresql.base import DatabaseWrapper
 new_connection = connection.copy()
 db_wrapper = DatabaseWrapper(new_connection.settings_dict)
 unsupported_version = new_connection.pg_version < 10

 # Test unsupported version
 msg = 'AutoField requires PostgreSQL 10+. Using SERIAL is
 supported in Django Version<3.0.'
 with self.assertRaisesMessage(NotSupportedError, msg):
 db_wrapper.features_class.changed_serial_to_identity =
 unsupported_version
 db_wrapper.check_supported()

 # After test should reset back to original state
 db_wrapper.features_class.changed_serial_to_identity =
 property(operator.attrgetter('db_wrapper.features_class.is_postgresql_10'))
 self.assertTrue(db_wrapper.features_class.changed_serial_to_identity !=
 unsupported_version)
 }}}


 2. List of where changes need to be made that I have found so far:
 ||=location=||=method=||=necessary changes=||
 ||django/db/backends/postgresql/base.py ||DatabaseWrapper.data_types||^^*
 serial → int GENERATED BY DEFAULT AS IDENTITY\\ ^^* bigserial → bigint
 GENERATED BY DEFAULT AS IDENTITY\\ ^^* smallserial → smallint GENERATED BY
 DEFAULT AS IDENTITY\\||
 ||django/db/backends/postgresql/operations.py
 ||DatabaseOperations.sequence_reset_by_name_sql
 (pg_get_serial_sequence)||need to write a function to find the sequence of
 an identity field||
 ||django/db/backends/postgresql/operations.py
 ||DatabaseOperations.sequence_reset_sql (pg_get_serial_sequence)||need to
 write a function to find the sequence of an identity field||
 ||django/db/backends/postgresql/schema.py
 ||DatabaseSchemaEditor._alter_column_type_sql||alterations for IDENTITY||

 Found unit-test locations:
 ||=location=||
 ||django/tests/db/backends/base/||
 ||django/tests/db/backends/postgresql/||
 ||django/tests/schema/||
 ||django/tests/postgres_tests/||

 I think for the sequences no real changes need to be made. Just all with
 the SERIAL-only parts. Are these all locations?

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

Re: [Django] #30732: The default SameSite cookie flag breaks xframe_options_exempt

2019-09-09 Thread Django
#30732: The default SameSite cookie flag breaks xframe_options_exempt
-+-
 Reporter:  Dan Braghis  |Owner:  Jezeniel
 Type:   |  Zapanta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  CSRF, SameSite,  | Triage Stage:  Accepted
  Clickjacking   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jezeniel Zapanta):

 * has_patch:  0 => 1


Comment:

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

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


Re: [Django] #29406: Add Referrer-Policy header support

2019-09-09 Thread Django
#29406: Add Referrer-Policy header support
-+-
 Reporter:  James Bennett|Owner:  James
 |  Bennett
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #29823: Incorrect Decimal handling in Sum queries

2019-09-09 Thread Django
#29823: Incorrect Decimal handling in Sum queries
--+
 Reporter:  Jurica Železnjak  |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 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
--+

Comment (by Nick Pope):

 Replying to [comment:11 Jurica Železnjak]:
 > And what about testing? We generally use inmemory-sqlite as a database
 when running tests.

 You should really be testing using the same database backend that you use
 in production.

 Otherwise there are any number of subtle bugs that you could encounter
 such as this 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ab828de57433e9f2810a68d35998f795%40djangoproject.com.


Re: [Django] #30746: Add Feature-Policy header support

2019-09-09 Thread Django
#30746: Add Feature-Policy header support
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Someday/Maybe


Comment:

 I agree with Adam, it's too early. This header is still under development
 and it isn't wide-supported.

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


Re: [Django] #30732: The default SameSite cookie flag breaks xframe_options_exempt

2019-09-09 Thread Django
#30732: The default SameSite cookie flag breaks xframe_options_exempt
-+-
 Reporter:  Dan Braghis  |Owner:  Jezeniel
 Type:   |  Zapanta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  CSRF, SameSite,  | Triage Stage:  Accepted
  Clickjacking   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Jezeniel Zapanta):

 Replying to [comment:2 Carlton Gibson]:
 > These topics are orthogonal, but, OK yes, often the reason to allow use
 in an iframe would be form submission.
 >
 > As such, a note in `docs/ref/clickjacking.txt` cross-linking to the
 `CSRF_COOKIE_SAMESITE` and/or `SESSION_COOKIE_SAMESITE` docs would seem
 appropriate.

 I have some questions regarding this, maybe this is somehow unrelated to
 the ticket but what if you just want to disable the `CSRF_COOKIE_SAMESITE`
 to a certain view? If we modify `CSRF_COOKIE_SAMESITE` it will be disabled
 globally, what if you want granular control over this? Will it be possibe?

 Will this also be possible?

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


Re: [Django] #30255: docutils reports an error rendering view docstring when the first line is not empty

2019-09-09 Thread Django
#30255: docutils reports an error rendering view docstring when the first line 
is
not empty
-+-
 Reporter:  Manlio Perillo   |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  contrib.admindocs|  Version:  2.1
 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 Markus Zapke-Gründemann):

 * cc: Markus Zapke-Gründemann (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.93f277cf049f760bf8889f43fe99779b%40djangoproject.com.


Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

2019-09-09 Thread Django
#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Accepted
  returning, default, model, field   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 This ticket is doable on Oracle with `cx_Oracle` 6.3+ (see
 [https://blogs.oracle.com/opal/python-cx_oracle-63-supports-dml-returning-
 for-batch-statement-execution cx_oracle-63-supports-dml-returning-for-
 batch-statement]) that's why I'm leaving it open. First attempt of fixing
 this on Oracle was a part of the original PR (see
 [https://code.djangoproject.com/attachment/ticket/29444/refs-29444-oracle-
 part.diff a diff]).

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


Re: [Django] #30746: Add Feature-Policy header support

2019-09-09 Thread Django
#30746: Add Feature-Policy header support
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 I'm -1 on adding Feature-Policy to Django... right now. It's far too
 experimental and evolving much faster than Django's release cycle.

 I created django-feature-policy to support it in October last year. Since
 then I've done two "breaking changes" releases to update to the supported
 set of headers: https://github.com/adamchainz/django-feature-
 policy/blob/master/HISTORY.rst

 It's still an actively developed w3c spec: https://github.com/w3c
 /webappsec-feature-policy/commits/master . Also on the MDN page the
 support grid shows that most support, even in Chrome, remains behind
 feature flags: https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Feature_Policy#Browser_compatibility

 I think it'll be settled in a year or so and then it'll be worth adding to
 Django core.

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


Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

2019-09-09 Thread Django
#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Ready for
  returning, default, model, field   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * Attachment "refs-29444-oracle-part.diff" 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.ed92493d43c25af81f4036a19646e355%40djangoproject.com.


Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

2019-09-09 Thread Django
#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Ready for
  returning, default, model, field   |  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:"736e7d44de395b867011ff9237dc5fdcfd28ee66" 736e7d44]:
 {{{
 #!CommitTicketReference repository=""
 revision="736e7d44de395b867011ff9237dc5fdcfd28ee66"
 Refs #29444 -- Fixed DateField constructor in
 db.backends.oracle.utils.InsertVar.
 }}}

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


Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

2019-09-09 Thread Django
#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Ready for
  returning, default, model, field   |  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:"7254f1138d9c51fa558229c39c9559b369c4278a" 7254f113]:
 {{{
 #!CommitTicketReference repository=""
 revision="7254f1138d9c51fa558229c39c9559b369c4278a"
 Refs #29444 -- Allowed returning multiple fields from INSERT statements on
 PostgreSQL.

 Thanks Florian Apolloner, Tim Graham, Simon Charette, Nick Pope, and
 Mariusz Felisiak for reviews.
 }}}

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


Re: [Django] #30757: Add check to ensure max_length fits longest choice.

2019-09-09 Thread Django
#30757: Add check to ensure max_length fits longest choice.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  master
  checks)|
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"b6251956b69512bf230322bd7a49b629ca8455c6" b6251956]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6251956b69512bf230322bd7a49b629ca8455c6"
 Fixed #30757 -- Added a system check to ensure max_length fits the longest
 choice.
 }}}

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


Re: [Django] #30767: Docs: deployment landing page is scarce

2019-09-09 Thread Django
#30767: Docs: deployment landing page is scarce
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 Type:   |  McLaughlin
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"1f304ebdc6ccdf42c8be96e972867981c7a0cb48" 1f304ebd]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f304ebdc6ccdf42c8be96e972867981c7a0cb48"
 [2.2.x] Fixed #30767 -- Improved references to deployment documentation.

 * Increased tocdepth to expose more complexity of topics.
 * Ensured deployment checklist is linked on main doc page.

 Backport of fee75d2aed4e58ada6567c464cfd22e89dc65f4a from master.
 }}}

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

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


Re: [Django] #30767: Docs: deployment landing page is scarce

2019-09-09 Thread Django
#30767: Docs: deployment landing page is scarce
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 Type:   |  McLaughlin
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"fee75d2aed4e58ada6567c464cfd22e89dc65f4a" fee75d2a]:
 {{{
 #!CommitTicketReference repository=""
 revision="fee75d2aed4e58ada6567c464cfd22e89dc65f4a"
 Fixed #30767 -- Improved references to deployment documentation.

 * Increased tocdepth to expose more complexity of topics.
 * Ensured deployment checklist is linked on main doc page.
 }}}

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


Re: [Django] #30754: Partial indexes break future migrations in sqlite

2019-09-09 Thread Django
#30754: Partial indexes break future migrations in sqlite
-+-
 Reporter:  Pēteris Caune|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Pēteris Caune):

 Hello Simon, tested your patch with the minimal reproduction case and also
 in the project where I first encountered the issue. Migrations now run
 without errors in both!

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


Re: [Django] #30767: Docs: deployment landing page is scarce

2019-09-09 Thread Django
#30767: Docs: deployment landing page is scarce
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 Type:   |  McLaughlin
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


Comment:

 Not a problem. Super improvement!

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


Re: [Django] #30426: Make security headers default.

2019-09-09 Thread Django
#30426: Make security headers default.
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"05d0eca635853564c57e639ac5590674a7de2ed6" 05d0eca6]:
 {{{
 #!CommitTicketReference repository=""
 revision="05d0eca635853564c57e639ac5590674a7de2ed6"
 Fixed #30426 -- Changed X_FRAME_OPTIONS setting default to DENY.
 }}}

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

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


Re: [Django] #30767: Docs: deployment landing page is scarce

2019-09-09 Thread Django
#30767: Docs: deployment landing page is scarce
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 Type:   |  McLaughlin
  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:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Katie McLaughlin):

 Whoops, sorry about 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.88d7d631afc1ee9135c66bfd2b3f52d7%40djangoproject.com.