Re: [Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+-
 Reporter:  Jeremy Kerr  |Owner:  Jeremy
 |  Kerr
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 Awesome, thank you for submitting a PR and adding a test!

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

[Django] #28553: Querysets: annotate() columns are forced into a certain position which may disrupt union()

[Django]

#28553: Querysets: annotate() columns are forced into a certain position which 
may
disrupt union()
-+-
   Reporter:  David  |  Owner:  nobody
  Sanders|
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 (Reporting possible issue found by a user on #django)

 Using values() to force selection of certain columns in a certain order
 proved useful unioning querysets with union() for the aforementioned user.
 The positioning of columns added with annotate() is not controllable with
 values() and has the potential to disrupt union() unless this fact is
 known and the ordering done in a certain way to accommodate it.

 I'm reporting this mainly for posterity but also as a highlight that
 perhaps this should be mentioned in the documentation.  I'm sure there are
 reasons why the annotations are appended to the select but if someone
 feels that this is changeable then it would be a bonus outcome.

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

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

Re: [Django] #28546: Django translations to_locale() function incorrectly formats private subtags

[Django]

#28546: Django translations to_locale() function incorrectly formats private
subtags
-+-
 Reporter:  Ronnie van den   |Owner:  Brent
  Crommenacker   |  Hand
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, translation,   | Triage Stage:  Accepted
  language   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Brent Hand):

 * has_patch:  0 => 1


Comment:

 I have added the check to make sure that subtags are formatted properly.
 Here is the link to the PR [https://github.com/django/django/pull/8995 ]

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

Re: [Django] #28500: "EOFError: Ran out of input" from Django file cache when file is empty

[Django]

#28500: "EOFError: Ran out of input" from Django file cache when file is empty
-+-
 Reporter:  Justin Crown |Owner:  caleb
 |  logan
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  1.11
 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 caleb logan):

 * owner:  nobody => caleb logan
 * 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/064.bf149b9d0c7bdc681d347888d2e0e61d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28552: Drop support for MySQL 5.5

[Django]

#28552: Drop support for MySQL 5.5
-+-
   Reporter:  Tim|  Owner:  nobody
  Graham |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The end of upstream support for MySQL 5.5 is December 2018. Django 1.11
 will be supported until April 2020 which is well past the EOL date. We
 don't have MySQL 5.5 running on our continuous integration servers which
 makes providing official support difficult.

 [https://groups.google.com/d/topic/django-
 developers/XXqGQH6BSpY/discussion django-developers thread]

 [https://github.com/django/django/pull/8980 PR]

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

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

Re: [Django] #27701: Document that runserver bypasses middleware for static files

[Django]

#27701: Document that runserver bypasses middleware for static files
-+-
 Reporter:  Kevin Christopher|Owner:  Joe
  Henry  |  Krzystan
 Type:   |   Status:  closed
  Cleanup/optimization   |
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 Tim Graham ):

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


Comment:

 In [changeset:"20a761697fd28c08ab82dec777b4056a5bfaf6a2" 20a76169]:
 {{{
 #!CommitTicketReference repository=""
 revision="20a761697fd28c08ab82dec777b4056a5bfaf6a2"
 Fixed #27701 -- Doc'd staticfiles runserver bypasses middleware when
 serving static files.
 }}}

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

Re: [Django] #27701: Document that runserver bypasses middleware for static files

[Django]

#27701: Document that runserver bypasses middleware for static files
-+-
 Reporter:  Kevin Christopher|Owner:  Joe
  Henry  |  Krzystan
 Type:   |   Status:  closed
  Cleanup/optimization   |
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 Tim Graham ):

 In [changeset:"046b8c80ce76ed1d410910aa92f67c405b8a15ba" 046b8c8]:
 {{{
 #!CommitTicketReference repository=""
 revision="046b8c80ce76ed1d410910aa92f67c405b8a15ba"
 [1.11.x] Fixed #27701 -- Doc'd staticfiles runserver bypasses middleware
 when serving static files.

 Backport of 20a761697fd28c08ab82dec777b4056a5bfaf6a2 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/065.5bbdf0e2707fa1b529ccd9eaa17623fc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+-
 Reporter:  Jeremy Kerr  |Owner:  Jeremy
 |  Kerr
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jeremy Kerr):

 * has_patch:  0 => 1


Comment:

 Pull request sent: [https://github.com/django/django/pull/8994 PR]

 Since this is a trivial patch (and my first), I've not added to `AUTHORS`
 or submitted a CLA. Let me know if I need to do either of those.

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

Re: [Django] #28550: auth's login/logout() views drop options passed as args rather the kwargs

[Django]

#28550: auth's login/logout() views drop options passed as args rather the 
kwargs
-+
 Reporter:  Clayton Daley|Owner:  Zach Liu
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.11
 Severity:  Release blocker  |   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 Zach Liu):

 * status:  new => assigned
 * cc: Zach Liu (added)
 * owner:  nobody => Zach Liu


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

Re: [Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+-
 Reporter:  Jeremy Kerr  |Owner:  Jeremy
 |  Kerr
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jeremy Kerr):

 * status:  new => assigned
 * owner:  nobody => Jeremy Kerr


Comment:

 Patch coming.

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

Re: [Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+-
 Reporter:  Jeremy Kerr  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jeremy Kerr):

 Replying to [comment:2 Simon Charette]:
 > I think your intuition is right and that the bug lies in
 `deferred_to_data()`. Could you try replacing `for field in
 model._meta.fields` by `for field in model._meta.local_fields` and see if
 it helps?

 Yep, that seems to fix the issue:

 {{{
 >>> Sub.objects.defer('f1', 'f2').query.sql_with_params()[0]
 u'SELECT "defer_base"."id", "defer_sub"."base_ptr_id" FROM "defer_sub"
 INNER JOIN "defer_base" ON ("defer_sub"."base_ptr_id" =
 "defer_base"."id")'
 }}}

 I was concerned that using `local_fields` would omit inherited fields from
 the query, but looks like that's not the case; inherited (but not
 deferred) fields work fine with that change:

 {{{#!python
 class Base(models.Model):
 f1 = models.CharField(max_length=10)
 f3 = models.CharField(max_length=10)

 class Sub(Base):
 f2 = models.CharField(max_length=10)
 }}}

 {{{
 >>> Sub.objects.defer('f1', 'f2').query.sql_with_params()[0]
 u'SELECT "defer_base"."id", "defer_base"."f3", "defer_sub"."base_ptr_id"
 FROM "defer_sub" INNER JOIN "defer_base" ON ("defer_sub"."base_ptr_id" =
 "defer_base"."id")'
 }}}

 ^^- correctly includes `f3` in the query. Behaviour also look to remain
 correct when only deferring fields from one class too.

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

[Django] #28551: Exclude query on M2M field with F() fails

[Django]

#28551: Exclude query on M2M field with F() fails
-+
   Reporter:  daishi |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.11
   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  |
-+
 Given the following models:
 {{{
 class A(models.Model):
 pass

 class B(models.Model):
 a = models.ManyToManyField(A)

 class C(models.Model):
 a = models.ForeignKey(A)
 b = models.ForeignKey(B)
 }}}
 The following test:
 {{{
 a1 = A()
 a1.save()
 a2 = A()
 a2.save()
 b1 = B()
 b1.save()
 b1.a.add(a1)
 b1.save()
 b2 = B()
 b2.save()
 b2.a.add(a2)
 b2.save()
 c1 = C(a=a1, b=b1)
 c1.save()
 c2 = C(a=a1, b=b2)
 c2.save()
 self.assertEqual(1, C.objects.filter(b__a=F('a')).count())
 self.assertEqual(1, C.objects.exclude(b__a=F('a')).count())
 }}}
 Fails with the following error:
 {{{
 OperationalError: no such column: U2.id
 }}}
 The SQL generated by Django for the `C.objects.exclude(b__a=F('a'))`
 fragment is logged as:
 {{{
 SELECT "a_c"."id", "a_c"."a_id", "a_c"."b_id" FROM "a_c" WHERE NOT
 ("a_c"."b_id" IN (SELECT U3."b_id" AS Col1 FROM "a_c" U0 INNER JOIN
 "a_b_a" U3 ON (U2."id" = U3."b_id") WHERE U3."a_id" = (U0."a_id"))) LIMIT
 21; args=()
 }}}
 As suggested in the error, the `U2` join table does not seem to be defined
 in the generated query.

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

Re: [Django] #28514: Clarify docs regarding idempotence of RelatedManager.add()

[Django]

#28514: Clarify docs regarding idempotence of RelatedManager.add()
-+-
 Reporter:  Дилян Палаузов   |Owner:  Jack
 Type:   |  Mustacato
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Martin):

 * stage:  Accepted => Ready for checkin


Comment:

 I've reviewed the PR, it all looks good to me.

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

Re: [Django] #27701: Document that runserver bypasses middleware for static files

[Django]

#27701: Document that runserver bypasses middleware for static files
-+-
 Reporter:  Kevin Christopher|Owner:  Joe
  Henry  |  Krzystan
 Type:   |   Status:  assigned
  Cleanup/optimization   |
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 Tim Martin):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #28073: RemoveField.state_forwards() crashes with AttributeError: 'NoneType' object has no attribute 'is_relation'

[Django]

#28073: RemoveField.state_forwards() crashes with AttributeError: 'NoneType' 
object
has no attribute 'is_relation'
-+
 Reporter:  Logan Gunthorpe  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 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 python-force):

 Testvinder add this line to the code and in the console you'll see where
 it breaks and that will give you idea where to look.

 {{{
 print app_label + " " + self.model_name_lower + " " + self.name
 }}}

 {{{
 def state_forwards(self, app_label, state):
 new_fields = []
 old_field = None
 print app_label + " " + self.model_name_lower + " " + self.name
 for name, instance in state.models[app_label,
 self.model_name_lower].fields:
 if name != self.name:
 new_fields.append((name, instance))
 else:
 old_field = instance
 state.models[app_label, self.model_name_lower].fields = new_fields
 # Delay rendering of relationships if it's not a relational field
 delay = not old_field.is_relation
 state.reload_model(app_label, self.model_name_lower, delay=delay)
 }}}

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

Re: [Django] #28550: auth's login/logout() views drop options passed as args rather the kwargs

[Django]

#28550: auth's login/logout() views drop options passed as args rather the 
kwargs
-+
 Reporter:  Clayton Daley|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Description changed by Tim Graham:

Old description:

> I'm using django-userena which passes a custom template name into
>
> {{{
> return Signout(request, next_page, template_name, *args, **kwargs)
> }}}
>
> By the time this call is converted to a view, the template_name reverts
> to the default ({{{registration/logged_out.html}}}).  If I convert the
> arg to a kwarg (in {{{userena}}}), the call works correctly so the issue
> seems to be the way the view is constructed (in
> {{{contrib.auth.views.logout()}}}:
>
> {{{
> return LogoutView.as_view(**kwargs)(request, *args, **kwargs)
> }}}
>
> Since {{{template_name}}} is passed as an arg, it isn't included in the
> call to {{{as_view()}}} that actually sets attributes (including
> {{{template_name}}}.  Before making this call, I suspect the
> {{{logout()}}} function should convert template_name (and possibly other
> args) into kwargs.

New description:

 I'm using [https://github.com/bread-and-pepper/django-
 userena/blob/7dfb3d5d148127e32f217a62096d507266a3a83c/userena/views.py#L493
 django-userena] which passes a custom template name into

 {{{
 from django.contrib.auth.views import logout as Signout
 
 return Signout(request, next_page, template_name, *args, **kwargs)
 }}}

 By the time this call is converted to a view, the template_name reverts to
 the default (`registration/logged_out.html`).  If I convert the arg to a
 kwarg (in `userena`), the call works correctly so the issue seems to be
 the way the view is constructed (in `contrib.auth.views.logout()`:
 {{{
 return LogoutView.as_view(**kwargs)(request, *args, **kwargs)`
 }}}
 Since `template_name` is passed as an arg, it isn't included in the call
 to `as_view()` that actually sets attributes (including `template_name`.
 Before making this call, I suspect the `logout()` function should convert
 template_name (and possibly other args) into kwargs.

--

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

Re: [Django] #28550: auth's login/logout() views drop options passed as args rather the kwargs (was: LogoutView loses template_name)

[Django]

#28550: auth's login/logout() views drop options passed as args rather the 
kwargs
-+
 Reporter:  Clayton Daley|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Release blocker  |   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):

 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Regression in 78963495d0caadb77eb97ccf319ef0ba3b204fb5.

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

Re: [Django] #27998: LogEntry messages do not list m2m fields that were changed when an object is changed via ModelAdmin

[Django]

#27998: LogEntry messages do not list m2m fields that were changed when an 
object
is changed via ModelAdmin
---+
 Reporter:  ljsjl  |Owner:  ljsjl
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.10
 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 Tim Graham):

 I found that this is a regression in Django 1.10 due to
 ded502024191053475bac811d365ac29dca1db61 and therefore should be fixed in
 the current stable branch, 1.11.x. The fix for #28543 fixes this issue in
 a better way (at the form level, rather than only in the admin) but I'm
 concerned that the approach I've proposed there, changing the return type
 of `ManyToManyField.value_from_object()`, is too risky for a stable
 release. I've proposed an [https://github.com/django/django/pull/8993
 alternate PR] that modifies `model_to_dict()` instead. It restores the
 behavior of `model_to_dict()` returning a list for `ManyToManyField` from
 before 67d984413c9540074e4fe6aa033081a35cf192bc.

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

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

Re: [Django] #28487: runserver crashes with UncodeDecodeError as of Django 1.11.4

[Django]

#28487: runserver crashes with UncodeDecodeError as of Django 1.11.4
-+-
 Reporter:  newerBkl |Owner:  Mark
 |  Rogaski
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.11
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * stage:  Accepted => Ready for checkin


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

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

[Django] #28550: LogoutView loses template_name

[Django]

#28550: LogoutView loses template_name
-+
   Reporter:  Clayton Daley  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.auth   |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 I'm using django-userena which passes a custom template name into

 {{{
 return Signout(request, next_page, template_name, *args, **kwargs)
 }}}

 By the time this call is converted to a view, the template_name reverts to
 the default ({{{registration/logged_out.html}}}).  If I convert the arg to
 a kwarg (in {{{userena}}}), the call works correctly so the issue seems to
 be the way the view is constructed (in {{{contrib.auth.views.logout()}}}:

 {{{
 return LogoutView.as_view(**kwargs)(request, *args, **kwargs)
 }}}

 Since {{{template_name}}} is passed as an arg, it isn't included in the
 call to {{{as_view()}}} that actually sets attributes (including
 {{{template_name}}}.  Before making this call, I suspect the
 {{{logout()}}} function should convert template_name (and possibly other
 args) into kwargs.

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

Re: [Django] #28546: Django translations to_locale() function incorrectly formats private subtags

[Django]

#28546: Django translations to_locale() function incorrectly formats private
subtags
-+-
 Reporter:  Ronnie van den   |Owner:  Brent
  Crommenacker   |  Hand
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, translation,   | Triage Stage:  Accepted
  language   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Brent Hand):

 * owner:  nobody => Brent Hand
 * 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/067.b9493c39fc2a8958518f0196afbfe79f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+-
 Reporter:  Jeremy Kerr  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 I think your intuition is right and that the bug lies in
 `deferred_to_data()`. Could you try replacing `for field in
 model._meta.fields` by `for field in model._meta.local_fields` and see if
 it helps?

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

Re: [Django] #28543: ModelForm.initial is affected while its bound instance's m2m field be set with new data

[Django]

#28543: ModelForm.initial is affected while its bound instance's m2m field be 
set
with new data
-+-
 Reporter:  Wonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  form | 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):

 I found that #27998 is a regression in Django 1.10 due to
 ded502024191053475bac811d365ac29dca1db61. The proposed patch here fixes
 that issue in a better way (at the form level, rather than only in the
 admin) but, with respect to the decision of how to fix that on
 stable/1.11.x, changing the return type of
 `ManyToManyField.value_from_object()` may be too risky for a stable
 release. Perhaps a less invasive fix for 1.11.x would restore the queryset
 to list conversion for ManyToManyFields in `model_to_dict()`.

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

Re: [Django] #28543: ModelForm.initial is affected while its bound instance's m2m field be set with new data

[Django]

#28543: ModelForm.initial is affected while its bound instance's m2m field be 
set
with new data
-+-
 Reporter:  Wonder   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  form | 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):

 * type:  Uncategorized => Bug
 * has_patch:  0 => 1
 * component:  Uncategorized => Database layer (models, ORM)
 * stage:  Unreviewed => Accepted


Comment:

 The lazy behavior of `ManyToManyField.value_from_object()` seems
 inconsistent with other fields. Fixing this would allow reverting the
 admin-specific fix for #27998.

 [https://github.com/django/django/pull/8992 PR]

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

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

Re: [Django] #28548: Remove usage of "middlewares" in documentation

[Django]

#28548: Remove usage of "middlewares" in documentation
-+-
 Reporter:  Joe Krzystan |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"10b54c8782e41efbad805e1f982ca2116c78191a" 10b54c87]:
 {{{
 #!CommitTicketReference repository=""
 revision="10b54c8782e41efbad805e1f982ca2116c78191a"
 [1.11.x] Fixed #28548 -- Replaced 'middlewares' with 'middleware' in docs.

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

Re: [Django] #28548: Remove usage of "middlewares" in documentation

[Django]

#28548: Remove usage of "middlewares" in documentation
-+-
 Reporter:  Joe Krzystan |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"da3a5cee4f06ed801c6fb42bd8995428ff0b28bf" da3a5cee]:
 {{{
 #!CommitTicketReference repository=""
 revision="da3a5cee4f06ed801c6fb42bd8995428ff0b28bf"
 Fixed #28548 -- Replaced 'middlewares' with 'middleware' in 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/063.8ad5cc20d47b931695ace5bc2735d806%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+-
 Reporter:  Jeremy Kerr  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Jeremy Kerr):

 * cc: Jeremy Kerr (added)
 * component:  Uncategorized => Database layer (models, ORM)
 * 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/067.74f3df43f27f316ca67a234ba0e17789%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28549: Can't defer() fields from super- and sub-class at the same time

[Django]

#28549: Can't defer() fields from super- and sub-class at the same time
-+
   Reporter:  Jeremy Kerr|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.11
   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  |
-+
 Using the models:

 {{{#!python
 from django.db import models

 class Base(models.Model):
 f1 = models.CharField(max_length=10)

 class Sub(Base):
 f2 = models.CharField(max_length=10)
 }}}

 it seems that I can't `defer()` both `f1` and `f2` in a single query:

 {{{
 >>> Sub.objects.defer('f1', 'f2').query.sql_with_params()[0]
 u'SELECT "defer_base"."id", "defer_base"."f1", "defer_sub"."base_ptr_id"
 FROM "defer_sub" INNER JOIN "defer_base" ON ("defer_sub"."base_ptr_id" =
 "defer_base"."id")'
 }}}

 (we're seeing `f1` in the SELECT value list).

 I seem to be able to defer `f1` or `f2` separately though.

 I'm no django hacker, but: it seems as though
 `django.db.models.sql.query.Query.deferred_to_data()` is iterating both
 models in the loop:

 {{{#!python
 #640:
 for model, values in six.iteritems(seen):
 for field in model._meta.fields:
 if field in values:
 continue
 }}}

 ^^- and so is discovering `f1` twice: once as `Base.f1` and again as
 `Sub.f1`. Since the `field in values` test only skips `Base.f1`, we're
 still left with `Sub.f1` in the `workset` dict.

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

Re: [Django] #28534: Changing JSONField on inline in admin doesn't always trigger change

[Django]

#28534: Changing JSONField on inline in admin doesn't always trigger change
-+-
 Reporter:  john-parton  |Owner:  hui shang
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by hui shang):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #28534: Changing JSONField on inline in admin doesn't always trigger change

[Django]

#28534: Changing JSONField on inline in admin doesn't always trigger change
-+-
 Reporter:  john-parton  |Owner:  hui shang
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by hui shang):

 Replying to [comment:6 john-parton]:
 > Replying to [comment:5 hui shang]:
 > > [https://github.com/django/django/pull/8989 PR]
 > >
 > > Hi, @john-partonm, for (1),  json.dumps works well, but I think str()
 is a good choice too, so I use it.
 >
 > Does str() always sort dictionary keys? I'm not totally sure, but under
 certain circumstances I think your fix might flag {'a': 1, 'b': 2} as
 being different from {'b': 2, 'a': 1}.
 >
 > Thanks for the quick response and your hard work!
 >
 > EDIT:
 >
 > At least with Python3.6, the string representation of two dicts can
 differ:
 >
 > {{{
 >   Python 3.6.1 (default, Dec 2015, 13:05:11)
 >   [GCC 4.8.2] on linux
 >left = {}
 >left['a'] = 1
 >left['b'] = 2
 >right = {}
 >right['b'] = 2
 >right['a'] = 1
 > str(left) == str(right)
 > => False
 > }}}

 Yes, you are right, thank you for the explanation.  I have changed the
 comparison from str() to json.dumps

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