Re: [Django] #29132: update_last_login signal handler shouldn't be connected if User.last_login attribute isn't a field

[Django]

#29132: update_last_login signal handler shouldn't be connected if 
User.last_login
attribute isn't a field
-+-
 Reporter:  Mikhail  |Owner:  Mikhail
  Porokhovnichenko   |  Porokhovnichenko
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  last_login,  | Triage Stage:  Accepted
  update_last_login, signals,|
  user_logged_in |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mikhail Porokhovnichenko):

 * owner:  nobody => Mikhail Porokhovnichenko
 * status:  new => assigned


Comment:

 Ok, will do it ASAP

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

Re: [Django] #29140: Exception sending EmailMessage with body=None

[Django]

#29140: Exception sending EmailMessage with body=None
+--
 Reporter:  Alex Schokking  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (Mail) |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Changes (by Alex Schokking):

 * type:  Uncategorized => Bug


Old description:

> This had been working fine on 1.9 but when we upgraded to 1.11 instantly
> started hitting an exception when django tries to call splitlines on the
> None body without checking if there's a value there to split on.
>
> {{{
>  File "/usr/local/lib/python2.7/dist-
> packages/django/core/mail/message.py", line 348, in send
> return self.get_connection(fail_silently).send_messages([self])
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/mail/backends/smtp.py", line 111, in send_messages
> sent = self._send(message)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/mail/backends/smtp.py", line 125, in _send
> message = email_message.message()
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/mail/message.py", line 307, in message
> msg = SafeMIMEText(self.body, self.content_subtype, encoding)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/mail/message.py", line 214, in __init__
> MIMEText.__init__(self, _text, _subtype=_subtype, _charset=_charset)
>   File "/usr/lib/python2.7/email/mime/text.py", line 30, in __init__
> self.set_payload(_text, _charset)
>   File "/usr/local/lib/python2.7/dist-
> packages/django/core/mail/message.py", line 224, in set_payload
> for l in payload.splitlines()
> AttributeError: 'NoneType' object has no attribute 'splitlines'
> }}}
>

> We've hacked around it by passing in an empty string instead but would
> probably be more elegant for this `has_long_lines` logic to check if
> there's a value instead.
>
> For context we're not passing in a body because we're attaching the
> plaintext and html versions of the email as a SafeMIMEMultipart
> attachment.

New description:

 This had been working fine on 1.9 but when we upgraded to 1.11 instantly
 started hitting an exception when django tries to call splitlines() on the
 None body without checking if there's a value there to split on.

 {{{
  File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 348, in send
 return self.get_connection(fail_silently).send_messages([self])
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/backends/smtp.py", line 111, in send_messages
 sent = self._send(message)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/backends/smtp.py", line 125, in _send
 message = email_message.message()
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 307, in message
 msg = SafeMIMEText(self.body, self.content_subtype, encoding)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 214, in __init__
 MIMEText.__init__(self, _text, _subtype=_subtype, _charset=_charset)
   File "/usr/lib/python2.7/email/mime/text.py", line 30, in __init__
 self.set_payload(_text, _charset)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 224, in set_payload
 for l in payload.splitlines()
 AttributeError: 'NoneType' object has no attribute 'splitlines'
 }}}


 We've hacked around it by passing in an empty string instead but would
 probably be more elegant for this `has_long_lines` logic to check if
 there's a value instead.

 For context we're not passing in a body because we're attaching the
 plaintext and html versions of the email as a SafeMIMEMultipart
 attachment.

--

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

[Django] #29140: Exception sending EmailMessage with body=None

[Django]

#29140: Exception sending EmailMessage with body=None
--+
   Reporter:  Alex Schokking  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Core (Mail) |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   |
--+
 This had been working fine on 1.9 but when we upgraded to 1.11 instantly
 started hitting an exception when django tries to call splitlines on the
 None body without checking if there's a value there to split on.

 {{{
  File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 348, in send
 return self.get_connection(fail_silently).send_messages([self])
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/backends/smtp.py", line 111, in send_messages
 sent = self._send(message)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/backends/smtp.py", line 125, in _send
 message = email_message.message()
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 307, in message
 msg = SafeMIMEText(self.body, self.content_subtype, encoding)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 214, in __init__
 MIMEText.__init__(self, _text, _subtype=_subtype, _charset=_charset)
   File "/usr/lib/python2.7/email/mime/text.py", line 30, in __init__
 self.set_payload(_text, _charset)
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/mail/message.py", line 224, in set_payload
 for l in payload.splitlines()
 AttributeError: 'NoneType' object has no attribute 'splitlines'
 }}}


 We've hacked around it by passing in an empty string instead but would
 probably be more elegant for this `has_long_lines` logic to check if
 there's a value instead.

 For context we're not passing in a body because we're attaching the
 plaintext and html versions of the email as a SafeMIMEMultipart
 attachment.

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

Re: [Django] #28379: Fix redirect loop in AccessMixin if a user lack permissions

[Django]

#28379: Fix redirect loop in AccessMixin if a user lack permissions
-+-
 Reporter:  Dylan Verheul|Owner:  Dylan
 |  Verheul
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  permissions  | 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:"9b1125bfc7e2dc747128e6e7e8a2259ff1a7d39f" 9b1125b]:
 {{{
 #!CommitTicketReference repository=""
 revision="9b1125bfc7e2dc747128e6e7e8a2259ff1a7d39f"
 Fixed #28379 -- Made AccessMixin raise Permissiondenied for authenticated
 users.
 }}}

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

Re: [Django] #29059: ChoiceWidget.optgroups() doesn't group choices without a group together

[Django]

#29059: ChoiceWidget.optgroups() doesn't group choices without a group together
-+-
 Reporter:  Riccardo Di  |Owner:  Abhishek
  Virgilio   |  Gautam
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.0
 Severity:  Normal   |   Resolution:  wontfix
 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 Tim Graham):

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


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

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

Re: [Django] #28398: Allow management command invocation to suggest commands for mistyped commands

[Django]

#28398: Allow management command invocation to suggest commands for mistyped
commands
-+-
 Reporter:  Vlada Macek  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.11
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 Potential PR: https://github.com/django/django/pull/9703

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

Re: [Django] #28762: Can't aggregate annotations with array parameters

[Django]

#28762: Can't aggregate annotations with array parameters
-+-
 Reporter:  Daniel Keller|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Tim Graham):

 #29139 is the same exception but a different cause involving aggregating
 `JSONField` with `KeyTransform`. The proposed patch doesn't fix that issue
 (not that is has to).

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

Re: [Django] #29062: "database table locked errors" when using sqlite in-memory database with LiveServerTestCase

[Django]

#29062: "database table locked errors" when using sqlite in-memory database with
LiveServerTestCase
-+-
 Reporter:  Juozas Masiulis  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, testing, | Triage Stage:
  databases  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Unfortunately your comment doesn't help with my understanding of the
 problem. Can explain why Django is at fault or propose a solution? If not,
 I'm not sure how to move this issue forward.

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

Re: [Django] #29133: call_command() fails if a required option is passed in via **options

[Django]

#29133: call_command() fails if a required option is passed in via **options
-+-
 Reporter:  Alex Tomic   |Owner:  Alex
 Type:   |  Tomic
  Cleanup/optimization   |   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
-+-

Comment (by Alex Tomic):

 Replying to [comment:2 Tim Graham]:
 > I'm not sure if the additional code complexity is worth supporting this.
 I noted this recommendation from the Python documentation, "Required
 options are generally considered bad form because users expect options to
 be optional, and thus they should be avoided when possible." An
 alternative could be to document the limitation.

 Thanks for the quick feedback.

 I figured this would be a 1-2 line fix, but it turned out to be a bit more
 complex than I thought. I agree it's a bit unnecessary given that the
 python docs recommend against this practice. Ironically, I ran up against
 this as I was trying to wrap a few such unwieldy management commands doing
 exactly that.

 I don't believe it is universally agreed upon that -/-- parameters should
 always be optional, though, outside of the Python world. Getopt_long [ 1 ]
 and the Open Group utility conventions [ 2 ], for example, don't recommend
 against it as far as I can tell.

 All that said, if this patch seems too risky to fix such a minor issue,
 I'd also be happy to contribute a documentation change instead.

 [1] https://www.gnu.org/software/libc/manual/html_node/Getopt-Long-
 Options.html#Getopt-Long-Options
 [2]
 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
 e.g. Section 12.1.9

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

Re: [Django] #29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use to_field

[Django]

#29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use
to_field
---+
 Reporter:  Jonathan Nye   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  autocomplete   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Jonathan Nye):

 Replying to [comment:2 Johannes Hoppe]:
 > Hi Jonathan,
 >
 > very good catch. This is certainly a bug. Custom to_fields should be
 supported.
 >
 > Do you want to fix this yourself or should I?
 >
 > Best
 > -Joe

 Hi Joe,

 I can give it a shot. I haven't contributed to Django before so I would
 appreciate some pointers to get me looking in the right direction.

 What would need to be updated?

 Regards,
 Jonathan

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

Re: [Django] #29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use to_field

[Django]

#29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use
to_field
---+
 Reporter:  Jonathan Nye   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  autocomplete   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Johannes Hoppe):

 Hi Jonathan,

 very good catch. This is certainly a bug. Custom to_fields should be
 supported.

 Do you want to fix this yourself or should I?

 Best
 -Joe

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

Re: [Django] #29062: "database table locked errors" when using sqlite in-memory database with LiveServerTestCase

[Django]

#29062: "database table locked errors" when using sqlite in-memory database with
LiveServerTestCase
-+-
 Reporter:  Juozas Masiulis  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, testing, | Triage Stage:
  databases  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Juozas Masiulis):

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


Comment:

 It is a race condition. It is consistent in my system, but it gets locked
 by node process, and I did not want to go outside of python to demonstrate
 the bug. It needs something faster to lock the database consistently.

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

Re: [Django] #29139: Aggregate functions failing when using Postgres JSON field KeyTransform

[Django]

#29139: Aggregate functions failing when using Postgres JSON field KeyTransform
-+-
 Reporter:  trik |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  json keytransform| Triage Stage:  Accepted
  unhashable |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Similar exception as #28762 but the fix there doesn't resolve 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/062.6fc8ae223e0f900b48e81a120d904d5a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29137: ModelForm, Generic Views and Generic Edit Views Custom Layout Simplification

[Django]

#29137: ModelForm, Generic Views and Generic Edit Views Custom Layout
Simplification
-+-
 Reporter:  Spleeding1   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  2.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 The ability to define fieldsets on forms is a duplicate of #6630 (closed
 as wontfix).

 Regarding automatically changing input boxes size based on `max_length` --
 that would be a rather disruptive change and not something that everyone
 would want. You could write a mixin for your forms to accomplish that.

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

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

Re: [Django] #29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use to_field (was: Admin autocomplete field doesn't support the 'to_field' on Foreign Keys)

[Django]

#29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use
to_field
---+
 Reporter:  Jonathan Nye   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  autocomplete   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * cc: Johannes Hoppe (added)
 * stage:  Unreviewed => Accepted


Comment:

 I think the correct solution is to modify `AutocompleteJsonView` to return
 the `to_field` value instead of the primary key. To prevent improper data
 leakage, `ModelAdmin.to_field_allowed()` should be called.

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

Re: [Django] #29136: CreateView documentation incomplete

[Django]

#29136: CreateView documentation incomplete
-+-
 Reporter:  Linurandy|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CreateView,  | Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Linurandy):

 that's right, sorry.

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

Re: [Django] #29132: update_last_login signal handler shouldn't be connected if User.last_login attribute isn't a field

[Django]

#29132: update_last_login signal handler shouldn't be connected if 
User.last_login
attribute isn't a field
-+-
 Reporter:  Mikhail  |Owner:  nobody
  Porokhovnichenko   |
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  last_login,  | Triage Stage:  Accepted
  update_last_login, signals,|
  user_logged_in |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Try the `isinstance()` approach. You're welcome to create a patch. Most of
 the work will be writing 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.40a287eb116c747e11224ef340c203b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29139: Aggregate functions failing when using Postgres JSON field KeyTransform

[Django]

#29139: Aggregate functions failing when using Postgres JSON field KeyTransform
-+-
   Reporter:  trik   |  Owner:  (none)
   Type:  Bug| Status:  new
  Component: |Version:  2.0
  contrib.postgres   |   Keywords:  json keytransform
   Severity:  Normal |  unhashable
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When annotating by a nested KeyTransform applied to a JSON field,
 aggregate functions fail:

 {{{#!python
 JSONModel.objects.annotate(history=KeyTransform('-1', 'field'))\
 .annotate(last_state=KeyTransform('state', 'history'))\
 .filter(last_state__gte=5).count()

 JSONModel.objects.annotate(history=KeyTransform('-1', 'field'))\
 .annotate(last_state=KeyTransform('state', 'history'))\
 .filter(last_state__isnull=False).aggregate(Sum('last_state'))
 }}}

 {{{
 Traceback (most recent call last):
   File
 "/Users/trik/Projects/3d_party/django/tests/postgres_tests/test_json.py",
 line 305, in test_keytransform
 .filter(last_state__gte=5).count(),
   File "/Users/trik/Projects/3d_party/django/django/db/models/query.py",
 line 384, in count
 return self.query.get_count(using=self.db)
   File
 "/Users/trik/Projects/3d_party/django/django/db/models/sql/query.py", line
 494, in get_count
 number = obj.get_aggregation(using, ['__count'])['__count']
   File
 "/Users/trik/Projects/3d_party/django/django/db/models/sql/query.py", line
 462, in get_aggregation
 outer_query.add_subquery(inner_query, using)
   File
 "/Users/trik/Projects/3d_party/django/django/db/models/sql/subqueries.py",
 line 193, in add_subquery
 self.subquery, self.sub_params =
 query.get_compiler(using).as_sql(with_col_aliases=True)
   File
 "/Users/trik/Projects/3d_party/django/django/db/models/sql/compiler.py",
 line 443, in as_sql
 extra_select, order_by, group_by = self.pre_sql_setup()
   File
 "/Users/trik/Projects/3d_party/django/django/db/models/sql/compiler.py",
 line 55, in pre_sql_setup
 group_by = self.get_group_by(self.select + extra_select, order_by)
   File
 "/Users/trik/Projects/3d_party/django/django/db/models/sql/compiler.py",
 line 130, in get_group_by
 if (sql, tuple(params)) not in seen:
 TypeError: unhashable type: 'list'
 }}}

 
[[https://github.com/gnucoop/django/commit/34769e05be720792e8afc2aebdac0230a77e04c0|Failing
 test case]]

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

Re: [Django] #29136: CreateView documentation incomplete

[Django]

#29136: CreateView documentation incomplete
-+-
 Reporter:  Linurandy|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CreateView,  | Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 The `Author` model defined above the code block you quoted has a
 `get_absolute_url()` method. Have I misunderstood the problem?

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

Re: [Django] #29132: update_last_login signal handler shouldn't be connected if User.last_login attribute isn't a field

[Django]

#29132: update_last_login signal handler shouldn't be connected if 
User.last_login
attribute isn't a field
-+-
 Reporter:  Mikhail  |Owner:  nobody
  Porokhovnichenko   |
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  last_login,  | Triage Stage:  Accepted
  update_last_login, signals,|
  user_logged_in |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mikhail Porokhovnichenko):

 Sorry, I didn't get it. What approach you'd like to use here? Need I
 create a patch?

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

Re: [Django] #28048: Allow generic date views to use related fields as date_field

[Django]

#28048: Allow generic date views to use related fields as date_field
-+-
 Reporter:  Lefteris Nikoltsios  |Owner:  Lefteris
 |  Nikoltsios
 Type:  New feature  |   Status:  assigned
Component:  Generic views|  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
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


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

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

[Django] #29138: Admin autocomplete field doesn't support the 'to_field' on Foreign Keys

[Django]

#29138: Admin autocomplete field doesn't support the 'to_field' on Foreign Keys
-+--
   Reporter:  Jonathan Nye   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  2.0
   Severity:  Normal |   Keywords:  autocomplete
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
 Hi,,

 I have encountered an issue where I have specified a 'to_field' in my
 foreign key and the autocomplete widget tries to enter the primary key of
 the related model instead. This means I cannot submit the form and I get
 the "Select a valid choice. That choice is not one of the available
 choices." error.

 In the AutocompleteJsonView:


 {{{

 def get(self, request, *args, **kwargs):
 """
 Return a JsonResponse with search results of the form:
 {
 results: [{id: "123" text: "foo"}],
 pagination: {more: true}
 }


return JsonResponse({
 'results': [
 {'id': str(obj.pk), 'text': str(obj)}
 for obj in context['object_list']
 ],
 'pagination': {'more': context['page_obj'].has_next()},
 })
 }}}


 Is there a way to replace the id manually when saving the form?

 Thanks.

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

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

Re: [Django] #25718: Can’t use queries with JSON ’null’ values with JSONField

[Django]

#25718: Can’t use queries with JSON ’null’ values with JSONField
-+-
 Reporter:  Dmitry Dygalo|Owner:  Dmitry
 |  Dygalo
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 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


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