Re: [Django] #12405: django.contrib.auth.views.logout() should support LOGOUT_REDIRECT_URL

[Django]

#12405: django.contrib.auth.views.logout() should support LOGOUT_REDIRECT_URL
-+-
 Reporter:  cmwslw   |Owner:  cbarcenas
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:  logout   | Triage Stage:  Accepted
  LOGOUT_REDIRECT_URL|
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cbarcenas):

 Picking this one up as my first contribution to Django :) I don't
 anticipate this taking more than a few lines of code and a test or two.

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

Re: [Django] #12405: django.contrib.auth.views.logout() should support LOGOUT_REDIRECT_URL

[Django]

#12405: django.contrib.auth.views.logout() should support LOGOUT_REDIRECT_URL
-+-
 Reporter:  cmwslw   |Owner:  cbarcenas
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:  logout   | Triage Stage:  Accepted
  LOGOUT_REDIRECT_URL|
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cbarcenas):

 * owner:   => cbarcenas
 * 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.8ffd8374d7ada364ddabfe538daf0720%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24423: Combine i18n template tag tests?

[Django]

#24423: Combine i18n template tag tests?
--+
 Reporter:  prestontimmons|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Internationalization  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I was working on #25372 and noticed there isn't an obvious place to add
 extra tests. This is because the `i18n` tag tests are currently split
 among `i18n` and `template_tests.syntax_tests.test_i18n`. I think these
 tests should be combined in one place or the other.

 I propose the following:

 1) Move the tag-related tests from `i18n` into `template_tests`
 2) Split `template_tests.syntax_tests.test_i18n` into separate files for
 each tag (test_trans.py, test_blocktrans.py, etc.)

 I think change 1 makes sense because `template_tests` is also where we
 have tests for things like staticfiles, cache, etc. The timezone tags are
 the only outlier here.

 Change 2 is a pattern we adopted when converting the filter tests to unit
 tests. I think it would be good for template tag tests to follow the same
 pattern.

 Does this seem like the right grouping?

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

Re: [Django] #24420: Can't order_by annotated field if annotated field uses conditional expression

[Django]

#24420: Can't order_by annotated field if annotated field uses conditional
expression
-+-
 Reporter:  krisfields   |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Uncategorized|  Version:  1.8beta1
 Severity:  Normal   |   Resolution:
 Keywords:  order_by,| Triage Stage:  Accepted
  annotation, conditional|
  expression |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => jarshwah
 * needs_docs:   => 0
 * stage:  Unreviewed => 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/068.973e425cf2e0daab00323007a1fa0cab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24422: Messages framework not correctly encoding messages

[Django]

#24422: Messages framework not correctly encoding messages
---+
 Reporter:  YPCrumble  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I'm using Django 1.7.5. I added the messages framework that added a cookie
 to my machine. When I send a request from my browser, my cookie is
 included in the following raw_cookie  string:

 'djdttop=29;
 
messages=71cd3671ca23bf7d6a599fb79d21a35c119780a4$[[\\"__json_message\\"\\0540\\05420\\054\\"This
 is my message.\\"]\\054[\\"__json_message\\"\\0540\\05425\\054\\"My second
 messages.\\"]]; sessionid=dqvje0lqh8czad0r7qxm2in4c7g3i25z;
 djdtRedirectsPanel=on; djdtSettingsPanel=off; djdtHeadersPanel=off;
 csrftoken=cRDz29PIcf0M2jmMgJdfehb8JUTvyPik; djdtTimerPanel=on; djdt=show'

 When python tries to decode this string (using Cookie.SmartCookie), it
 only outputs: 

 It's because my messages have been improperly encoded. If you take out the
 messages from the string, the rest of the cookies decode fine. Somehow
 Django isn't correctly encoding the messages cookie and it's interrupting
 other cookies in my browser.

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

[Django] #24421: Operational error when performing join using ForeignObject

[Django]

#24421: Operational error when performing join using ForeignObject
-+-
 Reporter:  animan1  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.7
  (models, ORM)  |   Keywords:  ForeignObject, MySQL,
 Severity:  Normal   |  SQLite
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 When joining on a field defined by a ForeignObject with multiple
 from_fields and to_fields, MySQL and SQLite throw operational errors. I
 have created a test cast which I know fails for SQLite and I assume fails
 for MySQL as well (I first saw the issue with production code using MySQL,
 but wanted to simplify the code submitted).

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

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

Re: [Django] #21495: Add a setting for CSRF Header name

[Django]

#21495: Add a setting for CSRF Header name
-+-
 Reporter:  hello@…  |Owner:  gregorth
 Type:  New feature  |   Status:  assigned
Component:  CSRF |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  csrf,header,angularjs  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gregorth):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


Comment:

 pr fixed, tests and documentation 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/077.d472803a617af5fa4c1c40e3418714bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23784: Error reporting docs needs to state clearly that changing logging conf error emails are not sent out unless configuring it again

[Django]

#23784: Error reporting docs needs to state clearly that changing logging conf
error emails are not sent out unless configuring it again
--+
 Reporter:  peterlauri|Owner:  gmunumel
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 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 gmunumel):

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

Re: [Django] #24340: Nested deconstruction does not descend into lists, tuples or dicts

[Django]

#24340: Nested deconstruction does not descend into lists, tuples or dicts
+
 Reporter:  gasman  |Owner:  gasman
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by gasman):

 @MarkusH - regarding the needs_documentation flag, is that something I can
 usefully work on? If so, can you let me know what sort of documentation
 you have in mind, as this doesn't seem like a particularly user-facing
 part of Django...?

 The nearest thing in the docs is probably
 https://docs.djangoproject.com/en/dev/topics/migrations/#serializing-
 values , and this already states that list/tuple/dict are supported (which
 is correct - serialization in general works, it's only the autodetector
 that has problems).

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

Re: [Django] #24115: Bcrypt hashers don't implement must_update

[Django]

#24115: Bcrypt hashers don't implement must_update
--+
 Reporter:  cancan101 |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * has_patch:  0 => 1
 * type:  Bug => New feature


Comment:

 [https://github.com/django/django/pull/4213 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/067.142d43e9188b3903b308d1c8d4dc8cf6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24420: Can't order_by annotated field if annotated field uses conditional expression

[Django]

#24420: Can't order_by annotated field if annotated field uses conditional
expression
-+-
 Reporter:   |  Owner:  nobody
  krisfields |
 Type:  Bug  | Status:  new
Component:   |Version:  1.8beta1
  Uncategorized  |   Keywords:  order_by, annotation, conditional
 Severity:  Normal   |  expression
 Triage Stage:   |  Has patch:  0
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 Continuing with the Client example on
 https://docs.djangoproject.com/en/dev/ref/models/conditional-expressions/


 {{{
 from django.db import models

 class Client(models.Model):
 REGULAR = 'R'
 GOLD = 'G'
 PLATINUM = 'P'
 ACCOUNT_TYPE_CHOICES = (
 (REGULAR, 'Regular'),
 (GOLD, 'Gold'),
 (PLATINUM, 'Platinum'),
 )
 name = models.CharField(max_length=50)
 registered_on = models.DateField()
 account_type = models.CharField(
 max_length=1,
 choices=ACCOUNT_TYPE_CHOICES,
 default=REGULAR,
 )

 Client.objects.annotate(
 discount=Case(
 When(account_type=Client.GOLD, then=Value('5%')),
 When(account_type=Client.PLATINUM, then=Value('10%')),
 default=Value('0%'),
 output_field=CharField(),
 ),
 ).order_by('discount')
 }}}

 Error is:

 {{{
 ) failed:
 AttributeError: 'WhereNode' object has no attribute 'resolve_expression'>
 }}}

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

Re: [Django] #24416: EmailMessage and send_email do not handle ugettext_lazy translated addresses correctly

[Django]

#24416: EmailMessage and send_email do not handle ugettext_lazy translated
addresses correctly
-+
 Reporter:  medmunds |Owner:  medmunds
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by medmunds):

 A reasonable use case is for the human-readable name -- you'd like the
 language on that to match the (lazy-translated) language of the email
 content:

 {{{
 "Customer Service "
 "Servicio Al Cliente "
 }}}

 It's not inconceivable that the address-part might change, too:

 {{{
 "Translation team "
 "Les traducteurs "
 }}}

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

Re: [Django] #24405: admin: cleanup Open related* popups code so it's easier to extend / replace

[Django]

#24405: admin: cleanup Open related* popups code so it's easier to extend / 
replace
--+
 Reporter:  rm_   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  popup admin modal | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => 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/061.79e587ae32147f6b9962d737b639d7e8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24419: Testing email settings

[Django]

#24419: Testing email settings
---+--
 Reporter:  gavinwahl  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Mail)|  Version:  master
 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 timgraham):

 I don't see much advantage to a management command compared to opening a
 shell and invoking `send_mail()` as you see fit (besides saving some
 keystrokes).

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

Re: [Django] #24419: Testing email settings

[Django]

#24419: Testing email settings
---+--
 Reporter:  gavinwahl  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Mail)|  Version:  master
 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 collinanderson):

 * cc: cmawebsite@… (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 The django developers list is usually the best place to discuss new
 features.

 My thoughts on your code:
  - If you set from_email=None, it should pick up the defaults
 automatically.
  - fail_silently defaults to False.

 Maybe it would be more useful to try to mimic the unix mail/sendmail
 commands, so you can use it even for non testing situations.

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

Re: [Django] #24406: SelectFilter should use click events instead of href javascript functions

[Django]

#24406: SelectFilter should use click events instead of href javascript 
functions
-+-
 Reporter:  rjagerman|Owner:  rjagerman
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin SelectFilter   | Triage Stage:
  javascript |  Unreviewed
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:"fa9cb5dcdc816fe0e606b8f1020d53526e08b0d4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fa9cb5dcdc816fe0e606b8f1020d53526e08b0d4"
 Fixed #24406 -- Improved SelectFilter js to use click events

 The SelectFilter widget used href to execute javascript. This was
 problematic if one wishes to customize the widget, since the href
 javascript is executed after events are handled. This change modifies
 the javascript to use click events to handle button 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/067.ff355f8b1f37702afce3a0965c66e4bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24419: Testing email settings

[Django]

#24419: Testing email settings
---+
 Reporter:  gavinwahl  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Core (Mail)|Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When configuring django to send emails through an SMTP server, there are
 usually many different settings to try to get it to work. I've written a
 management command that just sends an email to make testing the settings
 easier. I'm wonder if there's any interest in including this command in
 django?

 Here's the command: https://github.com/fusionbox/django-
 fusionbox/blob/master/fusionbox/core/management/commands/send_test_email.py

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

Re: [Django] #24418: refresh_from_db is breaking on null foreign keys

[Django]

#24418: refresh_from_db is breaking on null foreign keys
-+-
 Reporter:  ppp23|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8alpha1
  (models, ORM)  |
 Severity:  Release blocker  |   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 timgraham):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Reproduced with the attached 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/063.848555ddf0d3585a00277c4acef7cb6b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24410: MySQL manually created indexes aren't recognized

[Django]

#24410: MySQL manually created indexes aren't recognized
+--
 Reporter:  karolyi |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 timgraham):

 I'm having trouble understanding the steps to reproduce the issue. I had
 no trouble migrating this model:
 {{{
 class Image(models.Model):
 orig_src = models.URLField(verbose_name='Original source',
 max_length=512, db_index=True)
 }}}
 Python 3.4, MySQL 5.6.19, and mysqlclient 1.3.4.

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

Re: [Django] #24352: Coercing ManyRelatedManager to string raises StopIteration exception

[Django]

#24352: Coercing ManyRelatedManager to string raises StopIteration exception
-+-
 Reporter:  rasca|Owner:  gmunumel
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"0831a43c3afc3f93b8ed0c58630836e38248be12"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0831a43c3afc3f93b8ed0c58630836e38248be12"
 [1.7.x] Fixed #24352 -- Fixed crash when coercing ``ManyRelatedManager``
 to a string.
 }}}

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

[Django] #24418: refresh_from_db is breaking on null foreign keys

[Django]

#24418: refresh_from_db is breaking on null foreign keys
--+---
 Reporter:  ppp23 |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8alpha1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 If i try to call refresh_from_db on a model instance that has a foreignkey
 set to null, i get an error:

 {{{
 Traceback:
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/core/handlers/base.py" in get_response
   112. response = wrapped_callback(request,
 *callback_args, **callback_kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/contrib/admin/options.py" in wrapper
   465. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in _wrapped_view
   99. response = view_func(request, *args, **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/views/decorators/cache.py" in _wrapped_view_func
   52. response = view_func(request, *args, **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/contrib/admin/sites.py" in inner
   198. return view(request, *args, **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in _wrapper
   29. return bound_func(*args, **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in _wrapped_view
   99. response = view_func(request, *args, **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/utils/decorators.py" in bound_func
   25. return func(self, *args2, **kwargs2)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/db/transaction.py" in inner
   371. return func(*args, **kwargs)
 File "/home/johannes/formonauts/donation/.env/local/lib/python2.7/site-
 packages/django/contrib/admin/options.py" in add_view
   1164. self.save_model(request, new_object, form, False)
 File "/home/johannes/formonauts/donation/server/django-
 donut/donut/admin.py" in save_model
   36. obj.save()
 File "/home/johannes/formonauts/donation/server/django-
 donut/nanny/models.py" in save
   109. self.refresh_from_db()
 File "/home/johannes/formonauts/donation/server/django-
 donut/donut/basemodels.py" in refresh_from_db
   80. related_val = getattr(rel_instance,
 field.related_field.attname)

 Exception Type: AttributeError at /admin/nanny/team/add/
 Exception Value: 'NoneType' object has no attribute 'id'
 }}}

 here rel_instance is assigned:
 
https://github.com/django/django/blob/stable/1.8.x/django/db/models/base.py#L630

 if it is None (foreignkey not set, as it is nullable in this model) the
 getattr function will complain that it can not get 'id' from 'NoneType'

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

Re: [Django] #24416: EmailMessage and send_email do not handle ugettext_lazy translated addresses correctly

[Django]

#24416: EmailMessage and send_email do not handle ugettext_lazy translated
addresses correctly
-+
 Reporter:  medmunds |Owner:  medmunds
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by timgraham):

 I'm curious what the use case is for having translatable email addresses?

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

[Django] #24417: Django admin opton get_list_select_related is missing

[Django]

#24417: Django admin opton get_list_select_related is missing
---+
 Reporter:  eskhool|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Since other list options such as list_display has a corresponding dynamic
 function such as get_list_display, select_related should have the same to
 dynamically specify the related models to retrieve.

 Use case: If you dynamically include foreign key columns in list_display,
 then you would like the ability to dynamically specify the select_related
 also. Otherwise the queries are not as efficient as select_related allows
 them to be.

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

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

Re: [Django] #24340: Nested deconstruction does not descend into lists, tuples or dicts

[Django]

#24340: Nested deconstruction does not descend into lists, tuples or dicts
+
 Reporter:  gasman  |Owner:  gasman
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by gasman):

 * needs_better_patch:  1 => 0
 * needs_tests:  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/064.1cccbbe6128b9007dd6f205ec24a8843%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24323: NameError: global name XXXXXAdmin is not defined when using admin register decorator with an __init__ super call

[Django]

#24323: NameError: global name XAdmin is not defined when using admin 
register
decorator with an __init__ super call
---+
 Reporter:  eskhool|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by eskhool):

 Sounds like an unacceptable solution for now (I can confirm it works). The
 Python3 super may be a reasonable solution in the very long term.

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

Re: [Django] #24352: Coercing ManyRelatedManager to string raises StopIteration exception

[Django]

#24352: Coercing ManyRelatedManager to string raises StopIteration exception
-+-
 Reporter:  rasca|Owner:  gmunumel
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 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 gmunumel):

 New PR:
 
https://github.com/django/django/commit/798ed6f8aab97841d89e4659dbe74c9d35089b79

 Let me know if it's ok.

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

Re: [Django] #24317: Deprecate field.rel, replace it with real field instances

[Django]

#24317: Deprecate field.rel, replace it with real field instances
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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 akaariai):

 I've been working on this, with an approach where I completely deprecate
 field.rel with new reverse field instances.

 Unfortunately this seems to be an dead end for multiple reasons:
   - Patch implementing this would be huge: I'm currently at around 1700
 lines changed, and I still have probably at least 500 lines to change.
 These changes aren't systematic or easy to verify.
   - There is a huge risk of regressions, because of the size of the patch,
 and because it is nearly impossible to verify changes in the related
 fields code.
   - 3rd party software likely relies a lot on field.rel introspection.

 So, instead of trying to introduce a new field instance I think a better
 approach is to do incremental changes to the code. The idea is to
 continuously keep the field.rel as backwards compatible as possible while
 making it more like a relation field. The end result should be a situation
 where we can make field.rel a real field subclass.

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