Re: [Django] #29132: Incorrect update_last_login signal handler behavior when using custom User model with an arbitrary last_login attribute (not a Field instance)

2018-02-14 Thread Django 
#29132: Incorrect update_last_login signal handler behavior when using custom 
User
model with an arbitrary last_login attribute (not a Field instance)
-+-
 Reporter:  Mikhail  |Owner:  nobody
  Porokhovnichenko   |
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  last_login,  | Triage Stage:
  update_last_login, signals,|  Unreviewed
  user_logged_in |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Mikhail Porokhovnichenko:

Old description:

> **Please note! It's not a  #26823 duplicate, and it's just an issue
> related this one.**
>
> In the current implementation, a signal handler connects with a user
> model when this model has a `last_login` field.
>
> {{{
> #!python
> if hasattr(get_user_model(), 'last_login'):
> from .models import update_last_login
> user_logged_in.connect(update_last_login,
> dispatch_uid='update_last_login')
> }}}
>
> And it would work when there isn't a `last_login` attribute in the custom
> user model. But what if I've inherited my custom model from
> `AbstractUser` and dropped the `last_login` by setting it to `None`?
>
> {{{
> #!python
> class User(AbstractBaseUser):
> last_login = None # Drop ``last_login`` field off
> }}}
>
> Technically, the model has a ``last_login`` attribute, but it's not a
> field!
>
> Suggesting change the check condition something like that:
> {{{
> #!python
> last_login = getattr(get_user_model(), 'last_login', None)
> if last_login is not None:
> # ...
> }}}
> or even
> {{{
> #!python
> if isisintance(last_login, models.Field):
> # ...
> }}}

New description:

 **Please note! It's not a  #26823 duplicate, and it's just an issue
 related this one.**

 In the current implementation, a signal handler connects with a user model
 when this model has a `last_login` field.

 {{{
 #!python
 if hasattr(get_user_model(), 'last_login'):
 from .models import update_last_login
 user_logged_in.connect(update_last_login,
 dispatch_uid='update_last_login')
 }}}

 And it would work when there isn't a `last_login` attribute in the custom
 user model. But what if I've inherited my custom model from `AbstractUser`
 and dropped the `last_login` by setting it to `None`?

 {{{
 #!python
 class User(AbstractBaseUser):
 last_login = None # Drop ``last_login`` field off
 }}}

 Technically, the model has a `last_login` attribute, but it's not a field!

 Suggesting change the check condition something like that:
 {{{
 #!python
 last_login = getattr(get_user_model(), 'last_login', None)
 if last_login is not None:
 # ...
 }}}
 or even
 {{{
 #!python
 if isisintance(last_login, models.Field):
 # ...
 }}}

--

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

Re: [Django] #29133: django.core.management.call_command fails if required option passed in via **options

2018-02-14 Thread Django 
#29133: django.core.management.call_command fails if required option passed in 
via
**options
-+-
 Reporter:  Alex Tomic   |Owner:  Alex
 |  Tomic
 Type:  Uncategorized|   Status:  assigned
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex Tomic):

 * owner:  nobody => Alex Tomic


Comment:

 First time contributor, pardon for any newbie mistakes in the process!

 This bug has an easy workaround, but it cost me enough time today that I
 thought I would finally try to get my hands dirty in the code.  PR has
 been created here: https://github.com/django/django/pull/9701

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

[Django] #29133: django.core.management.call_command fails if required option passed in via **options

2018-02-14 Thread Django 
#29133: django.core.management.call_command fails if required option passed in 
via
**options
-+-
   Reporter:  Alex   |  Owner:  nobody
  Tomic  |
   Type: | Status:  assigned
  Uncategorized  |
  Component:  Core   |Version:  2.0
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 If `call_command` is called with a required option, e.g;

 {{{
 management.call_command('required_option',  "--need-me=asdf",  "--need-me-
 too=fdsa")
 management.call_command('required_option', need_me="asdf",
 need_me_too="fdsa")
 }}}

 The first call succeeds, but the second fails with an exception:

 {{{
 django.core.management.base.CommandError: Error: the following arguments
 are required: -n/--need-me, -t/--need-me-too
 }}}

 The problem is due to `parse_args` being called in `call_command` without
 checking for potentially required arguments in `**options`

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

[Django] #29132: Incorrect update_last_login signal handler behavior when using custom User model with an arbitrary last_login attribute (not a Field instance)

2018-02-14 Thread Django 
#29132: Incorrect update_last_login signal handler behavior when using custom 
User
model with an arbitrary last_login attribute (not a Field instance)
-+-
   Reporter:  Mikhail|  Owner:  nobody
  Porokhovnichenko   |
   Type:  Bug| Status:  new
  Component: |Version:  2.0
  contrib.auth   |   Keywords:  last_login,
   Severity:  Normal |  update_last_login, signals,
   Triage Stage: |  user_logged_in
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 **Please note! It's not a  #26823 duplicate, and it's just an issue
 related this one.**

 In the current implementation, a signal handler connects with a user model
 when this model has a `last_login` field.

 {{{
 #!python
 if hasattr(get_user_model(), 'last_login'):
 from .models import update_last_login
 user_logged_in.connect(update_last_login,
 dispatch_uid='update_last_login')
 }}}

 And it would work when there isn't a `last_login` attribute in the custom
 user model. But what if I've inherited my custom model from `AbstractUser`
 and dropped the `last_login` by setting it to `None`?

 {{{
 #!python
 class User(AbstractBaseUser):
 last_login = None # Drop ``last_login`` field off
 }}}

 Technically, the model has a ``last_login`` attribute, but it's not a
 field!

 Suggesting change the check condition something like that:
 {{{
 #!python
 last_login = getattr(get_user_model(), 'last_login', None)
 if last_login is not None:
 # ...
 }}}
 or even
 {{{
 #!python
 if isisintance(last_login, models.Field):
 # ...
 }}}

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

Re: [Django] #28693: DisallowedHost can cause uncaught exception and HTTP 500

2018-02-14 Thread Django 
#28693: DisallowedHost can cause uncaught exception and HTTP 500
-+-
 Reporter:  Greg Price   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  DisallowedHost   | 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 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"7ec0fdf62afd565dd9a888300e7e33d0bf3e5fd5" 7ec0fdf6]:
 {{{
 #!CommitTicketReference repository=""
 revision="7ec0fdf62afd565dd9a888300e7e33d0bf3e5fd5"
 Fixed #28693 -- Fixed crash in CsrfViewMiddleware when an HTTPS request
 has an invalid host.
 }}}

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

Re: [Django] #28933: Optimize the queries for ModelAdmin.date_hierarchy

2018-02-14 Thread Django 
#28933: Optimize the queries for ModelAdmin.date_hierarchy
--+
 Reporter:  hakib |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  2.0
 Severity:  Normal|   Resolution:  fixed
 Keywords:  date_hierarchy| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ff5517988adec04d364521fdaf4a36a3f88942ef" ff55179]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff5517988adec04d364521fdaf4a36a3f88942ef"
 Fixed #28933 -- Improved the efficiency of ModelAdmin.date_hierarchy
 queries.
 }}}

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

Re: [Django] #29131: Make the error message for ArrayField more user and translation-friendly

2018-02-14 Thread Django 
#29131: Make the error message for ArrayField more user and translation-friendly
--+
 Reporter:  Vlada Macek   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.postgres  |  Version:  2.0
 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:  1
--+

Comment (by Vlada Macek):

 > Changing array to list might be okay, but what about all the messages in
 the ArrayField model field that use "array".

 Quickly peeking... I'd say this could be the only message observable by
 the end user.

 > About the addition of "(count from the left)"... I think that would be
 better added in translational only for languages (if any?) where counting
 in lists happens from the right?

 I proposed such suboptimal wording rather to point out the non-technical
 people might not be even prepared to count items from either side.

 The resulting concatenated message for
 `ArrayField(base_field=models.EmailField)`  looks like this:

 `: Item %(nth)s in the array did not validate: Enter valid
 e-mail address`

 Personally I'd expect the value itself to be mentioned:

 `: One of the values in the list (%(value)s) did not validate:
 Enter valid e-mail address`

 > I guess the idea would be to modify
 `contrib.postgres.utils.prefix_validation_error()` to add the space
 instead.

 Exactly what I found out.

 Thank you.

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

Re: [Django] #29131: Make the error message for ArrayField more user and translation-friendly (was: Error message of ArrayField is unfriendly and has excessive trailing space)

2018-02-14 Thread Django 
#29131: Make the error message for ArrayField more user and translation-friendly
--+
 Reporter:  Vlada Macek   |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.postgres  |  Version:  2.0
 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:  1
--+
Changes (by Tim Graham):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I think indexing from 1 instead of 0 is an improvement.

 Changing array to list might be okay, but what about all the messages in
 the `ArrayField` model field that use "array".

 About the addition of "(count from the left)"... I think that would be
 better added in translational only for languages (if any?) where counting
 in lists happens from the right?

 I see your point about the trailing space -- the translated messages I
 checked don't have the trailing space. I guess the idea would be to modify
 `contrib.postgres.utils.prefix_validation_error()` to add the space
 instead.

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

Re: [Django] #29126: Document the behavior of QuerySet.update_or_create() with manually specified pks (was: Model.update_or_create method pk issue.)

2018-02-14 Thread Django 
#29126: Document the behavior of QuerySet.update_or_create() with manually
specified pks
--+
 Reporter:  Théo "Bob" Massard|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.0
 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 Tim Graham):

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


Comment:

 If I understand the situation you're describing, I believe this is
 expected behavior (see #8419). [https://github.com/django/django/pull/9698
 PR] to document and test it.

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

Re: [Django] #29010: Allow customizing the autocomplete search results based on the querying model

2018-02-14 Thread Django 
#29010: Allow customizing the autocomplete search results based on the querying
model
-+-
 Reporter:  Muslu Y. |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  ForeignKey,  | Triage Stage:
  get_search_results, search_fields  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Johannes Hoppe):

 * stage:  Accepted => Someday/Maybe


Comment:

 Hi there,

 currently you don't explicitly know who is calling this method, since it's
 all called from the same view. Both Widgets call the same view as the view
 is on AAdmin.
 So this is conceptually not supported. That doesn't mean it doesn't work.
 You can always check https://en.wikipedia.org/wiki/HTTP_referer

 To add a bit more context here, we did have an intermediate solution that
 would have made this easier. A view per widget. We ultimately dropped that
 approach to decrease complexity. A decision I still support.

 My suggestion would be use an external library like `django-select2` or
 `django-autocomplete` if you want to implement more sophisticated logic.
 Please also keep in mind, the admin is not recommend to be used for
 sofistikated user interfaces.

 Anyhow, at the moment I would strongly advice against adding a "hint" to
 the request. Since it's not safe against request forging and can lead to
 unintended security issues.

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

Re: [Django] #8851: Add a default option to list_filter in the admin interface

2018-02-14 Thread Django 
#8851: Add a default option to list_filter in the admin interface
-+-
 Reporter:  Riskable |Owner:  Harro
 |
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin, list_filter,  | Triage Stage:  Accepted
  default|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jonas Haag):

 That's a lot of code to copy and paste, and it's probably going to break
 when changes to the admin are being made.

 I'd say reopen this.

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

[Django] #29131: Error message of ArrayField is unfriendly and has excessive trailing space

2018-02-14 Thread Django 
#29131: Error message of ArrayField is unfriendly and has excessive trailing 
space
+
   Reporter:  Vlada Macek   |  Owner:  (none)
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  2.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  1 |
+
 There's an `'item_invalid'` error message
 `"Item %(nth)s in the array did not validate: "`

 that has problems:

 * While this message is shown to end user, it contains a 0-based index,
 which can be a challenge to explain, even in english...

 * I believe "list" would be a better term instead of "array" for general
 public. The same goes for my language.

 * Additional message is concatenated right after this, so the trailing
 space is needed in translations too. But on Transifex and many other i18n
 tools the space is not apparent.

 What about something like this:

 `"Item %(nth)s (count from the left) in the list is not valid:"`

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

Re: [Django] #21978: Add optional gunicorn support to runserver

2018-02-14 Thread Django 
#21978: Add optional gunicorn support to runserver
-+-
 Reporter:  Tim Graham   |Owner:  Berker
 |  Peksag
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Carlton Gibson (added)


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

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

Re: [Django] #28835: Development server doesn't shut down on SIGTERM

2018-02-14 Thread Django 
#28835: Development server doesn't shut down on SIGTERM
-+-
 Reporter:  Slavek Kabrda|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.11
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


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