Re: [Django] #28667: Documentation for extending UserCreationForm doesn't work with UserAdmin

2018-10-22 Thread Django
#28667: Documentation for extending UserCreationForm doesn't work with UserAdmin
-+-
 Reporter:  Nathanael Gordon |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  add_fieldsets| Triage Stage:  Accepted
  UserAdmin UserCreationForm Custom  |
  Auth User Model|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hampus Dunström):

 * owner:  Hampus Dunström => (none)
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.c35bdde1bbd907985821d1b66c34b9c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #15602: Using get_readonly_fields and StackedInline/TabularInline admin objects doesn't allow creating new objects, immutible existing objects

2018-10-22 Thread Django
#15602: Using get_readonly_fields and StackedInline/TabularInline admin objects
doesn't allow creating new objects, immutible existing objects
-+
 Reporter:  bradwhittington  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Scott Stevens):

 * cc: Scott Stevens (added)


Comment:

 This also affects `has__permission` calls, and actually causes the
 wrong object to be checked for permissions.

 I feel as though this increases the severity, since it no longer just
 affects what fields are read-only, but is now a failure to enforce
 permissions correctly (and could allow object permissions where it's
 expected to be prohibited).

 I'm unsure if we need a new bug for this, or to expand the scope of this
 existing ticket (rename/etc.).

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


Re: [Django] #29830: EmailMessage may ignore quote printable encoding

2018-10-22 Thread Django
#29830: EmailMessage may ignore quote printable encoding
-+-
 Reporter:  Jannik Schürg|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  email, mail, | Triage Stage:  Accepted
  encoding   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"efc0f77f02de86a94e21cafd3c8409eb7dd99ef6" efc0f77f]:
 {{{
 #!CommitTicketReference repository=""
 revision="efc0f77f02de86a94e21cafd3c8409eb7dd99ef6"
 Fixed #29830 -- Fixed loss of custom utf-8 body encoding in mails.
 }}}

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


Re: [Django] #29880: PasswordResetConfirmView docs refer to nonexistent set_password_form

2018-10-22 Thread Django
#29880: PasswordResetConfirmView docs refer to nonexistent set_password_form
-+-
 Reporter:  Timothy Hobbs|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"54732e2891e0fb92e6fa8c266522282e46d3a60a" 54732e28]:
 {{{
 #!CommitTicketReference repository=""
 revision="54732e2891e0fb92e6fa8c266522282e46d3a60a"
 [2.1.x] Fixed #29880 -- Fixed typo in docs/topics/auth/default.txt.

 Backport of 043407ec7e6e659a69c2432319140b4a813928d2 from master.
 }}}

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

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


Re: [Django] #29880: PasswordResetConfirmView docs refer to nonexistent set_password_form

2018-10-22 Thread Django
#29880: PasswordResetConfirmView docs refer to nonexistent set_password_form
-+-
 Reporter:  Timothy Hobbs|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"043407ec7e6e659a69c2432319140b4a813928d2" 043407ec]:
 {{{
 #!CommitTicketReference repository=""
 revision="043407ec7e6e659a69c2432319140b4a813928d2"
 Fixed #29880 -- Fixed typo in docs/topics/auth/default.txt.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.1d3339b992478f755f51e268b617f982%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29860: Allow BaseValidator to accept a callable limit_value

2018-10-22 Thread Django
#29860: Allow BaseValidator to accept a callable limit_value
-+-
 Reporter:  Javier Buzzi |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  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 Tim Graham ):

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


Comment:

 In [changeset:"24cae0bedc51093b363c323af555946a8edea1a1" 24cae0be]:
 {{{
 #!CommitTicketReference repository=""
 revision="24cae0bedc51093b363c323af555946a8edea1a1"
 Fixed #29860 -- Allowed BaseValidator to accept a callable limit_value.
 }}}

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

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


Re: [Django] #29880: PasswordResetConfirmView docs refer to nonexistent set_password_form

2018-10-22 Thread Django
#29880: PasswordResetConfirmView docs refer to nonexistent set_password_form
-+-
 Reporter:  Timothy Hobbs|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Timothy Hobbs):

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


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


Re: [Django] #29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting

2018-10-22 Thread Django
#29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting
--+
 Reporter:  Brenton Partridge |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf, settings| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by storymode7):

 Hey, can I take this up?

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


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Victor Porton):

 Replying to [comment:9 Simon Charette]:
 > The following should do

 My test with this patch passed.

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


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 The following should do

 {{{
 diff --git a/django/db/models/base.py b/django/db/models/base.py
 index 751f42bb9b..d3141d6180 100644
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -553,6 +553,8 @@ class Model(metaclass=ModelBase):
  return getattr(self, meta.pk.attname)

  def _set_pk_val(self, value):
 +for parent_link in self._meta.parents.values():
 +setattr(self, parent_link.target_field.attname, value)
  return setattr(self, self._meta.pk.attname, value)

  pk = property(_get_pk_val, _set_pk_val)
 }}}

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


Re: [Django] #29880: PasswordResetConfirmView docs refer to nonexistent set_password_form (was: PasswordResetConfirmView docs inconsistent)

2018-10-22 Thread Django
#29880: PasswordResetConfirmView docs refer to nonexistent set_password_form
-+-
 Reporter:  Timothy Hobbs|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Ready for checkin


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

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


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Victor Porton):

 Replying to [comment:7 Simon Charette]:
 > Could you confirm that the following patch work for you when setting
 `self.pk = None` in `reset()`.

 No, the patch does not make `self.pk = None` to work!

 {{{
 pip install django
 ...
 patch -p1 < ~/t/patch.diff
 cd /home/porton/Projects/test/testsave
 (env) testsave,0$ ./manage.py test
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 F
 ==
 FAIL: test_f_true (test1.tests.SaveTestCase)
 --
 Traceback (most recent call last):
   File "/home/porton/Projects/test/testsave/test1/tests.py", line 19, in
 test_f_true
 self.assertTrue(obj.f)
 AssertionError: False is not true

 --
 Ran 1 test in 0.005s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 }}}

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


[Django] #29880: PasswordResetConfirmView docs inconsistent

2018-10-22 Thread Django
#29880: PasswordResetConfirmView docs inconsistent
-+
   Reporter:  Timothy Hobbs  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |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  |
-+
 The docs for the PasswordResetConfirmView are in an inconsistent state.
 The docs say


 {{{
 * ``form``: The form (see ``set_password_form`` above) for setting the
   new user's password.
 }}}


 
https://github.com/django/django/blob/e40e7026cad400d720963aea0ba156a19f83b058/docs/topics/auth/default.txt#L1354

 And yet there is not description of **set_password_form** above.

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


Re: [Django] #27595: Database converters are not run for related fields referencing related fields

2018-10-22 Thread Django
#27595: Database converters are not run for related fields referencing related
fields
-+-
 Reporter:  oyooyo   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (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 ):

 * owner:  (none) => Tim Graham 


Comment:

 In [changeset:"5e3463f6bcec818431f0e1f4649d6a5bd944c459" 5e3463f6]:
 {{{
 #!CommitTicketReference repository=""
 revision="5e3463f6bcec818431f0e1f4649d6a5bd944c459"
 Fixed #27595 -- Made ForeignKey.get_col() follow target chains.

 Previously, foreign relationships were followed only one level deep which
 prevents foreign keys to foreign keys from being resolved appropriately.
 This was causing issues such as improper database value conversion for
 UUIDField on SQLite because the resolved expression's output field's
 internal type wasn't correct. Added tests to make sure unlikely foreign
 reference cycles don't cause recursion errors.

 Refs #24343.

 Thanks oyooyo for the report and Wayne Merry for the investigation.
 }}}

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


Re: [Django] #24343: UUID foreign key accessor returns inconsistent type

2018-10-22 Thread Django
#24343: UUID foreign key accessor returns inconsistent type
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"5e3463f6bcec818431f0e1f4649d6a5bd944c459" 5e3463f6]:
 {{{
 #!CommitTicketReference repository=""
 revision="5e3463f6bcec818431f0e1f4649d6a5bd944c459"
 Fixed #27595 -- Made ForeignKey.get_col() follow target chains.

 Previously, foreign relationships were followed only one level deep which
 prevents foreign keys to foreign keys from being resolved appropriately.
 This was causing issues such as improper database value conversion for
 UUIDField on SQLite because the resolved expression's output field's
 internal type wasn't correct. Added tests to make sure unlikely foreign
 reference cycles don't cause recursion errors.

 Refs #24343.

 Thanks oyooyo for the report and Wayne Merry for the investigation.
 }}}

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


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Thanks for the extra details Victor.

 Could you confirm that the following patch work for you when setting
 `self.pk = None` in `reset()`.

 {{{
 diff --git a/django/db/models/base.py b/django/db/models/base.py
 index 751f42bb9b..535928ce05 100644
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -553,7 +553,11 @@ class Model(metaclass=ModelBase):
  return getattr(self, meta.pk.attname)

  def _set_pk_val(self, value):
 -return setattr(self, self._meta.pk.attname, value)
 +field = self._meta.pk
 +setattr(self, field.attname, value)
 +while getattr(field, 'parent_link', False):
 +field = field.target_field
 +setattr(self, field.attname, value)

  pk = property(_get_pk_val, _set_pk_val)
 }}}

 This code should make sure that setting `self.pk = None` does
 `self.item_ptr_id = self.id = None` for any level of concrete model
 inheritance. That should be enough for `save()` to create new objects from
 my local testing.

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


Re: [Django] #29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting

2018-10-22 Thread Django
#29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting
--+
 Reporter:  Brenton Partridge |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  csrf, settings| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * type:  New feature => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I’m sympathetic to this. People have hit [https://github.com/encode
 /django-rest-framework/pull/6207 similar issues on DRF with
 `CSRF_USE_SESSIONS`].

 It’d at least be worth mentioning that you may have to include the CSRF
 token on the 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 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.1d2dcb8cb5c0b13ce7bbd0115eb9d1c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Victor Porton):

 Replying to [comment:5 Simon Charette]:
 > Hello Victor, could you provide more details about what exactly you are
 trying to achieve here?
 >
 > So far you've only provided a test case that fails. Are you trying to
 create a copy of an existing objects using MTI?

 Yes. I am trying to create a copy of an existing object using MTI.

 > Providing more details about what you are trying to achieve and why
 you're expecting the test to pass would help us to determining if this is
 actually a bug.

 I am trying to create a copy of a `Derived` object which was in the DB
 long before. The copy should contain all fields of the `Derived` model and
 all fields of its base models.

 As for now, I do not know a reliable and not error-prone (such as
 depending on usage of base of derived class) way to do this. If there is
 no such way, it is a missing feature in Django and this should be
 considered at least as a feature suggestion.

 In my real code I may have several levels of inheritance (not just `Item`
 and `Derived`).

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


Re: [Django] #29876: MySQL 8 fails to run GIS tests

2018-10-22 Thread Django
#29876: MySQL 8 fails to run GIS tests
+--
 Reporter:  Tom Forbes  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Florian Apolloner ):

 In [changeset:"4269648c0fe59a7edfa11f022f17cd251e9c49ca" 4269648c]:
 {{{
 #!CommitTicketReference repository=""
 revision="4269648c0fe59a7edfa11f022f17cd251e9c49ca"
 Fixed #29876 -- MySQL does not support SPATIAL fields in unique indices.
 }}}

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


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hello Victor, could you provide more details about what exactly you are
 trying to achieve here?

 So far you've only provided a test case that fails. Are you trying to
 create a copy of an existing objects using MTI?

 Providing more details about what you are trying to achieve and why you're
 expecting the test to pass would help us to determining if this is
 actually a bug.

 Thanks!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.4a39c35470e84fb7f99b39696466db41%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting

2018-10-22 Thread Django
#29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting
---+--
 Reporter:  Brenton Partridge  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  csrf, settings | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Brenton Partridge:

Old description:

> https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-httponly
> says:
>
> "If you enable this and need to send the value of the CSRF token with an
> AJAX request, your JavaScript must pull the value from a hidden CSRF
> token form input on the page instead of from the cookie."
>
> However, the documentation at
> https://docs.djangoproject.com/en/dev/ref/csrf/#ajax makes no mention of
> this setting; it's only barely listed at the bottom of the page. And if
> HttpOnly is set, then the recommendation to read the token from the
> cookie will fail.
>
> Anyone inheriting a codebase, or using a boilerplate that defaults
> CSRF_COOKIE_HTTPONLY to True, might naturally read the CSRF AJAX page,
> not even realize they need to check CSRF_COOKIE_HTTPONLY, and run into
> issues where it's clear that the CSRF cookie is being set in the
> browser's storage, but isn't readable by `Cookies.get('csrftoken')`
> (which is recommended as the "canonical way to do things").
>
> If our standard is to include code about how to read cookies, we
> shouldn't assume that the reader would instantly know that this mismatch
> is due to HttpOnly.
>
> I'd propose modifying the preface and relevant headings on that page
> from:
>
> First, you must get the CSRF token. How to do that depends on whether or
> not the CSRF_USE_SESSIONS setting is enabled.
>
> Acquiring the token if CSRF_USE_SESSIONS is False/True
>
> to:
>
> First, you must get the CSRF token. How to do that depends on whether or
> not the CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY setting is enabled.
>
> Acquiring the token if CSRF_COOKIE_HTTPONLY and CSRF_USE_SESSIONS are
> False
>
> Acquiring the token if CSRF_COOKIE_HTTPONLY or CSRF_USE_SESSIONS is True

New description:

 https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-httponly
 says:

 "If you enable this and need to send the value of the CSRF token with an
 AJAX request, your JavaScript must pull the value from a hidden CSRF token
 form input on the page instead of from the cookie."

 However, the documentation at
 https://docs.djangoproject.com/en/dev/ref/csrf/#ajax makes no mention of
 this setting; it's only barely listed at the bottom of the page. And if
 HttpOnly is set, then the recommendation to read the token from the cookie
 will fail.

 Anyone inheriting a codebase, or using a boilerplate that defaults
 CSRF_COOKIE_HTTPONLY to True, might naturally read the CSRF AJAX page, not
 even realize they need to check CSRF_COOKIE_HTTPONLY, and run into issues
 where it's clear that the CSRF cookie is being set in the browser's
 storage, but isn't readable by `Cookies.get('csrftoken')` (which is
 recommended as the "canonical way to do things").

 If our standard is to include code about how to read cookies, we shouldn't
 assume that the reader would instantly know that this mismatch is due to
 HttpOnly.

 I'd propose modifying the preface and relevant headings on that page from:


 {{{
 First, you must get the CSRF token. How to do that depends on whether or
 not the CSRF_USE_SESSIONS setting is enabled.

 Acquiring the token if CSRF_USE_SESSIONS is False/True
 }}}


 to:


 {{{
 First, you must get the CSRF token. How to do that depends on whether or
 not the CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY setting is enabled.

 Acquiring the token if CSRF_COOKIE_HTTPONLY and CSRF_USE_SESSIONS are
 False

 Acquiring the token if CSRF_COOKIE_HTTPONLY or CSRF_USE_SESSIONS is True
 }}}

--

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


[Django] #29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting

2018-10-22 Thread Django
#29879: CSRF AJAX section should warn about the CSRF_COOKIE_HTTPONLY setting
-+-
   Reporter:  Brenton|  Owner:  nobody
  Partridge  |
   Type:  New| Status:  new
  feature|
  Component: |Version:  master
  Documentation  |
   Severity:  Normal |   Keywords:  csrf, settings
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 https://docs.djangoproject.com/en/dev/ref/settings/#csrf-cookie-httponly
 says:

 "If you enable this and need to send the value of the CSRF token with an
 AJAX request, your JavaScript must pull the value from a hidden CSRF token
 form input on the page instead of from the cookie."

 However, the documentation at
 https://docs.djangoproject.com/en/dev/ref/csrf/#ajax makes no mention of
 this setting; it's only barely listed at the bottom of the page. And if
 HttpOnly is set, then the recommendation to read the token from the cookie
 will fail.

 Anyone inheriting a codebase, or using a boilerplate that defaults
 CSRF_COOKIE_HTTPONLY to True, might naturally read the CSRF AJAX page, not
 even realize they need to check CSRF_COOKIE_HTTPONLY, and run into issues
 where it's clear that the CSRF cookie is being set in the browser's
 storage, but isn't readable by `Cookies.get('csrftoken')` (which is
 recommended as the "canonical way to do things").

 If our standard is to include code about how to read cookies, we shouldn't
 assume that the reader would instantly know that this mismatch is due to
 HttpOnly.

 I'd propose modifying the preface and relevant headings on that page from:

 First, you must get the CSRF token. How to do that depends on whether or
 not the CSRF_USE_SESSIONS setting is enabled.

 Acquiring the token if CSRF_USE_SESSIONS is False/True

 to:

 First, you must get the CSRF token. How to do that depends on whether or
 not the CSRF_USE_SESSIONS or CSRF_COOKIE_HTTPONLY setting is enabled.

 Acquiring the token if CSRF_COOKIE_HTTPONLY and CSRF_USE_SESSIONS are
 False

 Acquiring the token if CSRF_COOKIE_HTTPONLY or CSRF_USE_SESSIONS is True

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


Re: [Django] #29871: Resetting primary key for a derived object does not work

2018-10-22 Thread Django
#29871: Resetting primary key for a derived object does not work
-+-
 Reporter:  Victor Porton|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Victor Porton):

 Can we consider that `self.pk = None` does not work too, as a bug?

 At least it is a counterintuitive (and dangerous for the data!) behavior.

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


Re: [Django] #29863: Allow configuration/customization of sensitive settings sanitization for error emails

2018-10-22 Thread Django
#29863: Allow configuration/customization of sensitive settings sanitization for
error emails
-+--
 Reporter:  Daniel Harding   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Carlton Gibson):

 Well, subclassing `ExceptionReporter` to override `get_traceback_data()` —
 in which you could filter any value you liked… — was the general idea.
 (Hence my thinking there’s maybe not much extra that would/could be needed
 here.)

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


Re: [Django] #27595: Database converters are not run for related fields referencing related fields

2018-10-22 Thread Django
#27595: Database converters are not run for related fields referencing related
fields
-+-
 Reporter:  oyooyo   |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (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 Ramiro Morales):

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


Comment:

 Fixed by 5e3463f6bcec818431f0e1f4649d6a5bd944c459.

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


Re: [Django] #29863: Allow configuration/customization of sensitive settings sanitization for error emails

2018-10-22 Thread Django
#29863: Allow configuration/customization of sensitive settings sanitization for
error emails
-+--
 Reporter:  Daniel Harding   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 It's unclear to me what customization hooks might be added as part of that
 ticket -- "Make it easier to customise ExceptionReporter output" is very
 broad and could mean many different things.

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


Re: [Django] #29872: ConnectionAbortedError from Chrome cancelled preload

2018-10-22 Thread Django
#29872: ConnectionAbortedError from Chrome cancelled preload
-+-
 Reporter:  William Hingston |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  ConnectionAbortedError Preload |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => HTTP handling
 * easy:  1 => 0


Comment:

 Do you have any idea about the root cause? Is Django definitely at fault
 or could it be a Python issue?

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


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Vishvajit Pathak):

 Thanks for the update Carlton Gibson.
 I think we should be updating with this link http://diveinto.org/python3/.
 As I see it as a best-legit option right now.

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


Re: [Django] #29875: Support GeoLite2 databases

2018-10-22 Thread Django
#29875: Support GeoLite2 databases
-+--
 Reporter:  Tom Forbes   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  2.1
 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:

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


Re: [Django] #29863: Allow configuration/customization of sensitive settings sanitization for error emails

2018-10-22 Thread Django
#29863: Allow configuration/customization of sensitive settings sanitization for
error emails
-+--
 Reporter:  Daniel Harding   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Error reporting  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Carlton Gibson):

 Hi Daniel.

 On top of this, is there anything here that **wouldn't be solved** if we
 had a solution to #29714? i.e. if you could customise the
 ExceptionReporter output what more would you need? (If nothing then it's a
 duplicate right?)

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


Re: [Django] #29875: Support GeoLite2 databases

2018-10-22 Thread Django
#29875: Support GeoLite2 databases
-+--
 Reporter:  Tom Forbes   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tom Forbes):

 Oh, right. I must have been reading the 1.11 docs when I made this ticket.
 Sorry!

 As 1.11 is going to be maintained past the time when GeoLite will be
 removed from their website, is it worth backporting this or adding some
 kind of note to the docs?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.4d19de77b09ad04ecde0b82ab13ed02f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Re: [Django] #29878: GEOSContextHandle leaks probably due to thread local object destructing order

2018-10-22 Thread Django
#29878: GEOSContextHandle leaks probably due to thread local object destructing
order
---+--
 Reporter:  yli-cpr|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  GEOS leak GIS  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by yli-cpr):

 * type:  Uncategorized => Bug


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

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


Re: [Django] #29875: Support GeoLite2 databases

2018-10-22 Thread Django
#29875: Support GeoLite2 databases
-+--
 Reporter:  Tom Forbes   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 The [https://docs.djangoproject.com/en/dev/ref/contrib/gis/geoip2/ geoip2]
 docs already reference GeoLite2. Those are the files that Jenkins is
 using. Did I miss something about what needs to be done?

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

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


Re: [Django] #29878: GEOSContextHandle leaks probably due to thread local object destructing order

2018-10-22 Thread Django
#29878: GEOSContextHandle leaks probably due to thread local object destructing
order
---+--
 Reporter:  yli-cpr|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  GIS|  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  GEOS leak GIS  | 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 yli-cpr:

Old description:

> I have observed consistent GEOSContextHandle leaks when using Django
> Geometry features in temporary threads. And I can avoid the leaks by
> manually clearing all attributes of
> `django.contrib.gis.geos.prototypes.io.thread_context`. My theory is that
> destructors of attributes in `io.thread_context` call some GEOSFunc
> objects, and that can create new GEOSContextHandle while Python is
> clearing thread local storage.
>
> 1. threadsafe.thread_context.handle is cleared
> 2. io.thread_context attributes are cleared
> 3. io.thread_context attributes are destructed, and then created new
> threadsafe.thread_context.handle.
>
> When I am trying a minimized sample, I also found that it got double free
> or corruption error very often if I do GC in main thread right after the
> thread using GEOS is joined. So this may be another big issue
>
> BTW, I am using Python 2.7.12 and django 1.11.  But after checking the
> latest Django code, I think the issue is still there.
>
> My sample code is:
>
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
> #!/usr/bin/env python
> import gc
> import threading
> from django.contrib.gis.geos import GEOSGeometry
>
> _old_objs = None
> _new_objs = None
> _first_time = True
>

> def gc_objects():
> gc.collect()
> objs_counts = {}
> gc_objs = {}
> for obj in gc.get_objects():
> key = str(type(obj))
> if key in objs_counts:
> objs_counts[key] += 1
> else:
> gc_objs[key] = obj
> objs_counts[key] = 1
> return objs_counts, gc_objs
>

> def dump_memory_leaks():
> global _old_objs
> global _new_objs
> global _first_time
> if _first_time:
> _old_objs, _ = gc_objects()
> _first_time = False
> else:
> _new_objs, gc_objs = gc_objects()
> leaked = {}
> for k, v in _new_objs.iteritems():
> old_v = _old_objs.get(k)
> if old_v:
> diff = _new_objs[k] - old_v
> if diff > 0:
> leaked[str(k)] = diff
> else:
> leaked[str(k)] = v
>
> print "Leaks: {}".format(leaked)
>
> _new_objs = None
>

> def use_geos():
> GEOSGeometry('POINT(5 23)')
> # These lines can get rid of the GEOSContextHandle leak
> # from django.contrib.gis.geos.prototypes.io import thread_context as
> io_thread_context
> # io_thread_context.__dict__.clear()
> dump_memory_leaks()
>

> if __name__ == '__main__':
> for i in xrange(10):
> t = threading.Thread(target=use_geos)
> t.start()
> t.join()
> # If I do GC here, it will crash with "double free or corruption"
> at random `i`
> # dump_memory_leaks()
>

>   }}}
> }}}
>
> Output:
>
> {{{
> Leaks: {"": 2, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 1,
> "": 1, " 'django.contrib.gis.geos.libgeos.LP_GEOSContextHandle_t'>": 1, " 'frame'>": 1}
> Leaks: {"": 2, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 2,
> "": 2,
> "": 4}
> Leaks: {"": 3, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 3,
> "": 3,
> "": 6}
> Leaks: {"": 4, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 4,
> "": 4,
> "": 8}
> Leaks: {"": 1, "": 5, " 'instancemethod'>": 1, " 'django.contrib.gis.geos.libgeos.LP_GEOSContextHandle_t'>": 5, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 5,
> "": 10}
> Leaks: {"": 6, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 6,
> "": 6,
> "": 12}
> Leaks: {"": 7, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 7,
> "": 7,
> "": 14}
> Leaks: {"": 8, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 8,
> "": 8,
> "": 16}
> Leaks: {"": 9, " 'django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle'>": 9,
> "": 9,
> "": 18}
>
> }}}

New description:

 I have observed consistent GEOSContextHandle leaks when using Django
 Geometry features in temporary threads. And I can avoid the leaks by
 manually clearing all attributes of
 `django.contrib.gis.geos.prototypes.io.thread_context`. 

Re: [Django] #29878: GEOSContextHandle leaks probably due to thread local object destructing order

2018-10-22 Thread Django
#29878: GEOSContextHandle leaks probably due to thread local object destructing
order
---+--
 Reporter:  yli-cpr|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  GIS|  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  GEOS leak GIS  | 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 yli-cpr:

Old description:

> I have observed consistent GEOSContextHandle leaks when using Django
> Geometry features in temporary threads. And I can avoid the leaks by
> manually clearing all attributes of
> `django.contrib.gis.geos.prototypes.io.thread_context`. My theory is that
> destructors of attributes in `io.thread_context` call some GEOSFunc
> objects, and that can create new GEOSContextHandle while Python is
> clearing thread local storage.
>
> 1. threadsafe.thread_context.handle is cleared
> 2. io.thread_context attributes are cleared
> 3. io.thread_context attributes are destructed, and then created new
> threadsafe.thread_context.handle.
>
> When I am trying a minimized sample, I also found that it got double free
> or corruption error very often if I do GC in main thread right after the
> thread using GEOS is joined. So this may be another big issue
>
> BTW, I am using Python 2.7.12 and django 1.11.  But after checking the
> latest Django code, I think the issue is still there.
>
> My sample code is:
>
> {{{
> #!div style="font-size: 80%"
> Code highlighting:
>   {{{#!python
> #!/usr/bin/env python
> import gc
> import threading
> from django.contrib.gis.geos import GEOSGeometry
>
> _old_objs = None
> _new_objs = None
> _first_time = True
>

> def gc_objects():
> gc.collect()
> objs_counts = {}
> gc_objs = {}
> for obj in gc.get_objects():
> key = str(type(obj))
> if key in objs_counts:
> objs_counts[key] += 1
> else:
> gc_objs[key] = obj
> objs_counts[key] = 1
> return objs_counts, gc_objs
>

> def dump_memory_leaks():
> global _old_objs
> global _new_objs
> global _first_time
> if _first_time:
> _old_objs, _ = gc_objects()
> _first_time = False
> else:
> _new_objs, gc_objs = gc_objects()
> leaked = {}
> for k, v in _new_objs.iteritems():
> old_v = _old_objs.get(k)
> if old_v:
> diff = _new_objs[k] - old_v
> if diff > 0:
> leaked[str(k)] = diff
> else:
> leaked[str(k)] = v
>
> print "Leaks: {}".format(leaked)
>
> _new_objs = None
>

> def use_geos():
> GEOSGeometry('POINT(5 23)')
> # These lines can get rid of the GEOSContextHandle leak
> # from django.contrib.gis.geos.prototypes.io import thread_context as
> io_thread_context
> # io_thread_context.__dict__.clear()
> dump_memory_leaks()
>

> if __name__ == '__main__':
> for i in xrange(10):
> t = threading.Thread(target=use_geos)
> t.start()
> t.join()
> # If I do GC here, it will crash with "double free or corruption"
> at random `i`
> # dump_memory_leaks()
>

>   }}}
> }}}

New description:

 I have observed consistent GEOSContextHandle leaks when using Django
 Geometry features in temporary threads. And I can avoid the leaks by
 manually clearing all attributes of
 `django.contrib.gis.geos.prototypes.io.thread_context`. My theory is that
 destructors of attributes in `io.thread_context` call some GEOSFunc
 objects, and that can create new GEOSContextHandle while Python is
 clearing thread local storage.

 1. threadsafe.thread_context.handle is cleared
 2. io.thread_context attributes are cleared
 3. io.thread_context attributes are destructed, and then created new
 threadsafe.thread_context.handle.

 When I am trying a minimized sample, I also found that it got double free
 or corruption error very often if I do GC in main thread right after the
 thread using GEOS is joined. So this may be another big issue

 BTW, I am using Python 2.7.12 and django 1.11.  But after checking the
 latest Django code, I think the issue is still there.

 My sample code is:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 #!/usr/bin/env python
 import gc
 import threading
 from django.contrib.gis.geos import GEOSGeometry

 _old_objs = None
 _new_objs = None
 _first_time = True


 def gc_objects():
 gc.collect()
 objs_counts = {}
 gc_objs = {}
 for obj in gc.get_objects():
 key = str(type(obj))
 if key in objs_counts:
 objs_cou

Re: [Django] #29876: MySQL 8 fails to run GIS tests

2018-10-22 Thread Django
#29876: MySQL 8 fails to run GIS tests
+--
 Reporter:  Tom Forbes  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Florian Apolloner):

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


Comment:

 Fixed in
 
https://github.com/django/django/commit/4269648c0fe59a7edfa11f022f17cd251e9c49ca

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


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Mark's Wikipedia page suggests http://diveinto.org/python3/ as the mirror
 to use, and this is functional as of now, so I'd guess go for 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/062.32ba661acc62d9e6ad749eea18e282f8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29873: Link to access related field on the admin tool

2018-10-22 Thread Django
#29873: Link to access related field on the admin tool
+--
 Reporter:  J. Pablo Fernández  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Carlton Gibson):

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


Comment:

 Hi.

 I'm going to close this as ''needs info'' as is.

 The change link already is a "View" link. The admin's Change Form just is
 its ''View'' page. Since 2.1, if you have only view permissions the link
 presented is already differently. (See
 
https://github.com/django/django/blob/c53af5661313079d022553b6c775e6c4f8d34927/django/contrib/admin/templates/admin/related_widget_wrapper.html#L6-L18)

 The only thing I can see here is that the link is currently opened in a
 popup. You can get around this via your browser's ability to open the link
 in a new tab (say), although you need to remove the `&_popup=1` to get the
 full admin shown. I don't know that a change would be merited here. (Or
 exactly what that feature would amount to...)

 If you want to develop this further could I suggest thinking through the
 exact behaviour you'd want and a post to
 [http://groups.google.com/forum/#!forum/django-developers the django-
 developers mailing list] to see if there would be support for your
 proposed change.

 Thanks.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.5551cc26dc3e4fcaf854188ec24dd0b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Vishvajit Pathak):

 Thanks Carlton Gibson.

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


Re: [Django] #29874: Typo in "Writing your first Django app, part2".

2018-10-22 Thread Django
#29874: Typo in "Writing your first Django app, part2".
-+-
 Reporter:  wonhyeongseo |Owner:  Vishvajit
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  typo | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 I think either `.schema` or `.tables` is fine. (`.schema` gives the full
 SQL vs just the table name.)

 Admittedly the `.table` command is probably closer in output to the other
 examples for the other DBs but I don't think the change is worth
 triggering re-translations. As such, I'll opt for `wontfix`.

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

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


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * version:  2.1 => master
 * stage:  Unreviewed => Accepted


Comment:

 OK, this is valid (http://diveintopython3.net/ is not resolving properly.)

 I pinged Mark Pilgrim to see if he could advise on the situation. (Let's
 see if he comes back.)

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


Re: [Django] #29860: Allow BaseValidator to accept a callable limit_value

2018-10-22 Thread Django
#29860: Allow BaseValidator to accept a callable limit_value
-+-
 Reporter:  Javier Buzzi |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  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
-+-

Comment (by Javier Buzzi):

 LOL. I did my best. Documentation is not my strong suit.

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

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


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by John Fitzpatrick):

 Replying to [comment:2 Vishvajit Pathak]:
 > John Fitzpatrick,
 >
 > Could you please post the related django documentation links for
 reference ?

 Hi — I encountered it when reading the index of the intro page, however
 I've just done a grep of all the documentation in current `HEAD`of
 `master` and found six references in total:

 {{{
 intro/contributing.txt:46:__ http://www.diveintopython3.net/
 intro/contributing.txt:336:__ http://www.diveintopython3.net/unit-
 testing.html
 intro/index.txt:39:.. _Dive Into Python:
 http://www.diveintopython3.net/
 ref/templates/builtins.txt:2095:http://www.diveintopython3.net/native-
 datatypes.html#slicinglists
 ref/django-admin.txt:1617:.. _import search path:
 http://www.diveintopython3.net/your-first-python-
 program.html#importsearchpath
 topics/settings.txt:49:.. _import search path:
 http://www.diveintopython3.net/your-first-python-
 program.html#importsearchpath
 }}}

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


Re: [Django] #29877: Dive Into Python 3 links in documentation no longer valid

2018-10-22 Thread Django
#29877: Dive Into Python 3 links in documentation no longer valid
-+-
 Reporter:  John Fitzpatrick |Owner:  Vishvajit
 |  Pathak
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vishvajit Pathak):

 * owner:  nobody => Vishvajit Pathak
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.447e4e77d1c5316533c5305f5f81e9a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.