Re: [Django] #26524: Change foreign key id list_display reference to display only the id

2016-05-10 Thread Django
#26524: Change foreign key id list_display reference to display only the id
-+-
 Reporter:  cristianocca |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  admin list_display   | Triage Stage:  Accepted
  changelist |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by krisys):

 @timgraham, Any update on this? Will be glad to work on anything that can
 make the review and merge process easy w.r.t this 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/070.cf7309b72925c6e00407ee90b5e3ec02%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26604: Add example of simple multiple file upload in documentation

2016-05-10 Thread Django
#26604: Add example of simple multiple file upload in documentation
-+-
 Reporter:  zxcq544  |  Owner:  nobody
 Type:  New  | Status:  new
  feature|
Component:   |Version:  1.9
  Documentation  |   Keywords:  doumentation, multiple file upload,
 Severity:  Normal   |  upload many files
 Triage Stage:   |  Has patch:  0
  Unreviewed |
Easy pickings:  0|  UI/UX:  0
-+-
 At https://docs.djangoproject.com/en/1.9/topics/http/file-uploads/  we
 could add simple example of multiple file upload:

 In views.py
 {{{
 def handle_uploaded_files(files):
 for i in files:
 with open('uploads/' + i.name, 'wb+') as destination:
 for chunk in i.chunks():
 destination.write(chunk)


 def upload_file(request):
 if request.method == 'POST':
 handle_uploaded_files(request.FILES.getlist('files[]'))
 return render(request, 'upload.html')
 }}}

 In upload.html

 {{{
 
 {% csrf_token %}
 
 
 
 }}}

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


Re: [Django] #26588: Unable to reverse a run_before that refers to django.contrib.auth

2016-05-10 Thread Django
#26588: Unable to reverse a run_before that refers to django.contrib.auth
+-
 Reporter:  schinckel   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.9
 Severity:  Normal  |   Resolution:  duplicate
 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 charettes):

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


Comment:

 Closing as duplicate of #24075.

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


Re: [Django] #24100: Make `post_migrate` dispatch the migration plan.

2016-05-10 Thread Django
#24100: Make `post_migrate` dispatch the migration plan.
-+
 Reporter:  charettes|Owner:  MarkusH
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  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 charettes):

 * needs_better_patch:  1 => 0


Comment:

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


Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2016-05-10 Thread Django
#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Removing the special case in `model_to_dict()` seems feasible:
 [https://github.com/django/django/pull/6585 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/066.2c54bd54d0acc0f5454c64dfd62f0b5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26602: RawSQL window functions break count()

2016-05-10 Thread Django
#26602: RawSQL window functions break count()
-+-
 Reporter:  daggaz   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * cc: josh.smeaton@… (added)
 * version:  1.9 => master
 * stage:  Unreviewed => Accepted


Comment:

 This happens because RawSQL defines:

 {{{
 def get_group_by_cols(self):
 return [self]
 }}}

 It'd be helpful if there was a way to disable grouping in an easy way. For
 the moment, you should be able to do something like:

 {{{
 window = RawSQL("SUM(amount) OVER (ORDER BY created)", [])
 window.get_group_by_cols = lambda: []
 qs = A.objects.annotate(total=window)
 qs.count()

 # Or..

 RawAggregate(RawSQL):
 contains_aggregate = True  # may not be necessary in newer django
 versions
 def get_group_by_cols(self):
 return []

 qs = A.objects.annotate(total=RawAggregate("SUM(amount) OVER (ORDER BY
 created)", []))
 }}}

 Can you let me know if this workaround helps you?

 In the meantime, I think it's worth figuring out how we want to treat
 RawSQL when it should not be doing group bys, so I'm accepting on that
 basis.

 Two options I see. First, we can define a whole new class as I've done
 above - like RawAggregate. Second, we could use a kwarg to RawSQL to tweak
 whether or not it contains aggregate code.

 {{{
 RawSQL('SELECT SUM() ..', [], grouping=False)
 }}}

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


Re: [Django] #26596: Document {{ csrf_input }} in Jinja2 templates

2016-05-10 Thread Django
#26596: Document {{ csrf_input }} in Jinja2 templates
---+-
 Reporter:  aaugustin  |Owner:  betojulio
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-

Comment (by betojulio):

 ok, I am working on 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/067.f24fd58c052b73563264a65e74122562%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24046: Deprecate the "escape" half of django.utils.safestring (was: Consider deprecating the "escape" half of django.utils.safestring)

2016-05-10 Thread Django
#24046: Deprecate the "escape" half of django.utils.safestring
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

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


Re: [Django] #26277: The list_display for CharField doesn't work for None value among choices

2016-05-10 Thread Django
#26277: The list_display for CharField doesn't work for None value among choices
-+-
 Reporter:  PetrDlouhy   |Owner:
 |  vincepandolfo
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  list_filter  | Triage Stage:  Accepted
  CharField admin|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by vincepandolfo):

 * needs_better_patch:  1 => 0


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

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


Re: [Django] #18100: Deleting model instances with deferred fields don't trigger deletion signals

2016-05-10 Thread Django
#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  deferred delete  | Triage Stage:  Ready for
  signals|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"535660b852c8899a17b82d20a06c926d8d437db3" 535660b8]:
 {{{
 #!CommitTicketReference repository=""
 revision="535660b852c8899a17b82d20a06c926d8d437db3"
 Refs #18100 -- Added tests for deferred model deletion signals.

 Thanks Tim for the review and pointing out this was fixed by #26207.
 }}}

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


Re: [Django] #18100: Deleting model instances with deferred fields don't trigger deletion signals

2016-05-10 Thread Django
#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  deferred delete  | Triage Stage:  Ready for
  signals|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


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

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


Re: [Django] #26585: Cascade-deletion through generic foreign keys ignores field names

2016-05-10 Thread Django
#26585: Cascade-deletion through generic foreign keys ignores field names
-+-
 Reporter:  nicklecoder  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  genericforeignkey| Triage Stage:
  delete |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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


Comment:

 The report looks a bit suspicious to me.

 In order to make `Location` deletion cascades to `Link` a
 `GenericRelation` has to be defined on the former which is not the case
 here.

 Please re-open this ticket if you can provide more details about your
 model definitions and an actual traceback.

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


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"de22123d3f0eab9495f2f04f972a3bcee7ad1b1c" de22123d]:
 {{{
 #!CommitTicketReference repository=""
 revision="de22123d3f0eab9495f2f04f972a3bcee7ad1b1c"
 [1.9.x] Refs #26603 -- Defined lazystr for a template loader test.

 Thanks vytisb for the report.
 }}}

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


Re: [Django] #25044: Renaming a ManyToManyField's through table creates a broken migration

2016-05-10 Thread Django
#25044: Renaming a ManyToManyField's through table creates a broken migration
+
 Reporter:  Ian-Foote   |Owner:  vytisb
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.8
 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 vytisb):

 * owner:   => vytisb
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/6584 PR] based on a fix in
 [changeset:"107c9f545346149b03354678f53a177709edaced" 107c9f5] for a
 similar 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.58676b76f05c8a5c8b63d15d463f8d47%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I'll take care of 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/064.b18e3c66c9c8e955081a9f39268beb5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vytisb):

 The last commit breaks tests in 1.9 because `lazystr` doesn't exist yet.

 {{{
 ==
 ERROR: template_tests.test_loaders (unittest.loader.ModuleImportFailure)
 --
 Traceback (most recent call last):
   File "/usr/lib64/python3.4/unittest/case.py", line 58, in
 testPartExecutor
 yield
   File "/usr/lib64/python3.4/unittest/case.py", line 577, in run
 testMethod()
   File "/usr/lib64/python3.4/unittest/loader.py", line 32, in testFailure
 raise exception
 ImportError: Failed to import test module: template_tests.test_loaders
 Traceback (most recent call last):
   File "/usr/lib64/python3.4/unittest/loader.py", line 312, in _find_tests
 module = self._get_module_from_name(name)
   File "/usr/lib64/python3.4/unittest/loader.py", line 290, in
 _get_module_from_name
 __import__(name)
   File "/home/vytis/src/django/tests/template_tests/test_loaders.py", line
 16, in 
 from django.utils.functional import lazystr
 ImportError: cannot import name 'lazystr'
 }}}

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


Re: [Django] #26596: Document {{ csrf_input }} in Jinja2 templates

2016-05-10 Thread Django
#26596: Document {{ csrf_input }} in Jinja2 templates
---+-
 Reporter:  aaugustin  |Owner:  betojulio
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-

Comment (by aaugustin):

 I believe this information would be more discoverable in the CSRF
 reference documentation, either in the "How to use it" section or in a new
 section.

 We should talk about:
 - the API offered by built-in template backends
 - requirements for third-party backends, as described in PEP 182
 (basically they have to provide a solution, but that solution isn't
 specified)

 This will likely require tweaking the content a bit to clarify that the
 main examples are specific to Django templates.

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


Re: [Django] #26596: Document {{ csrf_input }} in Jinja2 templates

2016-05-10 Thread Django
#26596: Document {{ csrf_input }} in Jinja2 templates
---+-
 Reporter:  aaugustin  |Owner:  betojulio
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-

Comment (by betojulio):

 Hi I just uploaded a diff file. Are this the changes needed?
 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/067.7487a48632d8ff2b72ec0666b6e9f512%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26596: Document {{ csrf_input }} in Jinja2 templates

2016-05-10 Thread Django
#26596: Document {{ csrf_input }} in Jinja2 templates
---+-
 Reporter:  aaugustin  |Owner:  betojulio
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by betojulio):

 * Attachment "26596.diff" added.

 diff file

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


Re: [Django] #26596: Document {{ csrf_input }} in Jinja2 templates

2016-05-10 Thread Django
#26596: Document {{ csrf_input }} in Jinja2 templates
---+-
 Reporter:  aaugustin  |Owner:  betojulio
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by betojulio):

 * cc: betojulio@… (added)
 * owner:  nobody => betojulio
 * status:  new => assigned


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

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


Re: [Django] #9475: add(), create(), etc. should be supported by intermediate ManyToMany model with extra attributes if extra fields can be calculated

2016-05-10 Thread Django
#9475: add(), create(), etc. should be supported by intermediate ManyToMany 
model
with extra attributes if extra fields can be calculated
-+-
 Reporter:  omat@…   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 ad-m):

 * cc: naczelnik-djangoproject@… (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/073.b00c9780e0e2f19a531fd246f0b56559%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #21523: Models DateField to_python method no longer supports mock dates.

2016-05-10 Thread Django
#21523: Models DateField to_python method no longer supports mock dates.
-+-
 Reporter:  hugo@…   |Owner:  akki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (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 akki):

 @claudep I have updated my [https://github.com/django/django/pull/6468
 PR]. Please see if that agrees with what you were looking for.

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


Re: [Django] #26524: Change foreign key id list_display reference to display only the id

2016-05-10 Thread Django
#26524: Change foreign key id list_display reference to display only the id
-+-
 Reporter:  cristianocca |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  admin list_display   | Triage Stage:  Accepted
  changelist |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Brobin:

Old description:

> Given these two models.
>

> {{{
> class A(models.Model):
> name = models.CharField(max_length=100)
>
> def __unicode__(self):
> return self.name
>
> class B(models.Model):
> name = models.CharField(max_length=100)
> fk = models.ForeignKey(A)
>
> def __unicode__(self):
> return self.name
> }}}
>
> And these model admin
>

> {{{
> class AAdmin(admin.ModelAdmin):
> list_display = ('id','name')
> admin.site.register(A, AAdmin)
>
> class BAdmin(admin.ModelAdmin):
> list_display = ('id','name','fk_id','fk')
> admin.site.register(B, BAdmin)
> }}}
>
> As you see, for BAdmin I'm trying to display the actual id of the foreign
> key, so I prevent an additional unwanted join (or worse, one query per
> related object if no select related is added). However, the admin page
> refuses to display the id and instead renders the whole object (calling
> the __unicode__ method) which causes the additional join I don't want.
> In order to demostrate it I also added the 'fk' relation which works as
> expected
>
> The change list result is then
>

> {{{
> 1   test B  test A  test A
> }}}
>
> where it should be
>
> {{{
> 1   test B  1   test A
> }}}
>

> In order to work around it, I can define a callable that just returns the
> id property, but that's terrible because I lose any sort option on it
> plus I need to write quite a few more lines.

New description:

 Given these two models.


 {{{#!python
 class A(models.Model):
 name = models.CharField(max_length=100)

 def __unicode__(self):
 return self.name

 class B(models.Model):
 name = models.CharField(max_length=100)
 fk = models.ForeignKey(A)

 def __unicode__(self):
 return self.name
 }}}

 And these model admin


 {{{#!python
 class AAdmin(admin.ModelAdmin):
 list_display = ('id','name')
 admin.site.register(A, AAdmin)

 class BAdmin(admin.ModelAdmin):
 list_display = ('id','name','fk_id','fk')
 admin.site.register(B, BAdmin)
 }}}

 As you see, for BAdmin I'm trying to display the actual id of the foreign
 key, so I prevent an additional unwanted join (or worse, one query per
 related object if no select related is added). However, the admin page
 refuses to display the id and instead renders the whole object (calling
 the __unicode__ method) which causes the additional join I don't want.
 In order to demostrate it I also added the 'fk' relation which works as
 expected

 The change list result is then


 {{{
 1   test B  test A  test A
 }}}

 where it should be

 {{{
 1   test B  1   test A
 }}}


 In order to work around it, I can define a callable that just returns the
 id property, but that's terrible because I lose any sort option on it plus
 I need to write quite a few more lines.

--

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


Re: [Django] #26585: Cascade-deletion through generic foreign keys ignores field names

2016-05-10 Thread Django
#26585: Cascade-deletion through generic foreign keys ignores field names
-+-
 Reporter:  nicklecoder  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  genericforeignkey| Triage Stage:
  delete |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Brobin:

Old description:

> Create three models:
>
> {{{
> from django.db import models
> from django.contrib.contenttypes import generic
>

> class Location(models.Model):
> address_line1 = models.CharField()
>
> class Account(models.Model):
> acct_number = models.CharField()
>
> class Link(models.Model):
> account = models.ForeignKey(Account)
> linked_object_id = models.PositiveIntegerField()
> linked_object_content_type = models.ForeignKey(ContentType)
> linked_object =
> generic.GenericForeignKey('linked_object_content_type',
> 'linked_object_id')
> }}}
>
> With this setup, deleting a `Location` object will attempt to cascade-
> delete any associated `Link` objects. In doing so, Django ignores the
> parameters to the `GenericForeignKey` field constructor and instead
> expects the content type to be in a field called `content_type` and the
> object id in `object_id`. This prevents cascade deletion through generic
> foreign keys from working whenever these fields aren't named as expected
> or whenever there are multiple generic foreign keys in a model.

New description:

 Create three models:

 {{{#!python
 from django.db import models
 from django.contrib.contenttypes import generic


 class Location(models.Model):
 address_line1 = models.CharField()

 class Account(models.Model):
 acct_number = models.CharField()

 class Link(models.Model):
 account = models.ForeignKey(Account)
 linked_object_id = models.PositiveIntegerField()
 linked_object_content_type = models.ForeignKey(ContentType)
 linked_object =
 generic.GenericForeignKey('linked_object_content_type',
 'linked_object_id')
 }}}

 With this setup, deleting a `Location` object will attempt to cascade-
 delete any associated `Link` objects. In doing so, Django ignores the
 parameters to the `GenericForeignKey` field constructor and instead
 expects the content type to be in a field called `content_type` and the
 object id in `object_id`. This prevents cascade deletion through generic
 foreign keys from working whenever these fields aren't named as expected
 or whenever there are multiple generic foreign keys in a model.

--

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


Re: [Django] #26602: RawSQL window functions break count()

2016-05-10 Thread Django
#26602: RawSQL window functions break count()
-+-
 Reporter:  daggaz   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Brobin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> I wanted to annotate my objects with a running total:
>
> {{{
> class A(models.Model):
> amount = models.IntegerField()
> created = models.DateTimeField(auto_now_add=True)
>
> qs = A.objects.annotate(total=RawSQL("SUM(amount) OVER (ORDER BY
> created)", []))
> }}}
>
> That works fine, and I get a running total for each object, but I cannot
> call `count()` on that queryset:
> {{{
> >>> qs.count()
> Traceback...
> ProgrammingError: window functions not allowed in GROUP BY clause
> }}}
>
> Using `extra()`, I can get the same annotation behaviour as well being
> able to call `count()`:
> {{{
> >>> qs = A.objects.extra(select={'total': 'SUM(amount) OVER (ORDER BY
> created)'})
> >>> qs.count()
> 8
> }}}

New description:

 I wanted to annotate my objects with a running total:

 {{{#!python
 class A(models.Model):
 amount = models.IntegerField()
 created = models.DateTimeField(auto_now_add=True)

 qs = A.objects.annotate(total=RawSQL("SUM(amount) OVER (ORDER BY
 created)", []))
 }}}

 That works fine, and I get a running total for each object, but I cannot
 call `count()` on that queryset:
 {{{
 >>> qs.count()
 Traceback...
 ProgrammingError: window functions not allowed in GROUP BY clause
 }}}

 Using `extra()`, I can get the same annotation behaviour as well being
 able to call `count()`:
 {{{
 >>> qs = A.objects.extra(select={'total': 'SUM(amount) OVER (ORDER BY
 created)'})
 >>> qs.count()
 8
 }}}

--

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


Re: [Django] #26586: makemigrations does not detect custom field subclassing change

2016-05-10 Thread Django
#26586: makemigrations does not detect custom field subclassing change
-+-
 Reporter:  tuffnatty|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, custom   | Triage Stage:  Accepted
  fields |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Brobin:

Old description:

> Example:
> {{{
> class MyLongTextField(models.CharField):
> def __init__(self, *args, **kwargs):
> kwargs["max_length"] = 2000
> super(MyLongTextField, self).__init__(*args, **kwargs)
> }}}
> After changing this to
> {{{
> class MyLongTextField(models.TextField):
> def __init__(self, *args, **kwargs):
> kwargs["max_length"] = 2000
> super(MyLongTextField, self).__init__(*args, **kwargs)
> }}}
> manage.py makemigrations detects no changes.

New description:

 Example:
 {{{#!python
 class MyLongTextField(models.CharField):
 def __init__(self, *args, **kwargs):
 kwargs["max_length"] = 2000
 super(MyLongTextField, self).__init__(*args, **kwargs)
 }}}
 After changing this to
 {{{#!python
 class MyLongTextField(models.TextField):
 def __init__(self, *args, **kwargs):
 kwargs["max_length"] = 2000
 super(MyLongTextField, self).__init__(*args, **kwargs)
 }}}
 manage.py makemigrations detects no changes.

--

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


Re: [Django] #24046: Consider deprecating the "escape" half of django.utils.safestring

2016-05-10 Thread Django
#24046: Consider deprecating the "escape" half of django.utils.safestring
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2f0e0eee450775a71ac3eb42707dcd970ede42c8" 2f0e0eee]:
 {{{
 #!CommitTicketReference repository=""
 revision="2f0e0eee450775a71ac3eb42707dcd970ede42c8"
 Fixed #24046 -- Deprecated the "escape" half of utils.safestring.
 }}}

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


Re: [Django] #26572: Remove email subject length truncation in AdminEmailHandler

2016-05-10 Thread Django
#26572: Remove email subject length truncation in AdminEmailHandler
-+-
 Reporter:  pdewacht |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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


Re: [Django] #17281: AdminErrorHandler silently fails if the log message contains newlines

2016-05-10 Thread Django
#17281: AdminErrorHandler silently fails if the log message contains newlines
-+-
 Reporter:  russellm |Owner:  marw85
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"c3e108694966f045adcc0ba11133a2b3bf238770" c3e10869]:
 {{{
 #!CommitTicketReference repository=""
 revision="c3e108694966f045adcc0ba11133a2b3bf238770"
 Stopped truncating AdminEmailHandler message subjects

 Refs #26572, #17281. The RFC doesn't limit total length, just the line
 length
 which is already taken care of by Python itself.
 Thanks Tim Graham for the review.
 }}}

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


Re: [Django] #26572: Remove email subject length truncation in AdminEmailHandler

2016-05-10 Thread Django
#26572: Remove email subject length truncation in AdminEmailHandler
-+-
 Reporter:  pdewacht |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"c3e108694966f045adcc0ba11133a2b3bf238770" c3e10869]:
 {{{
 #!CommitTicketReference repository=""
 revision="c3e108694966f045adcc0ba11133a2b3bf238770"
 Stopped truncating AdminEmailHandler message subjects

 Refs #26572, #17281. The RFC doesn't limit total length, just the line
 length
 which is already taken care of by Python itself.
 Thanks Tim Graham for the review.
 }}}

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


Re: [Django] #24227: isinstance checks on ManyToManyField should be replaced with field.many_to_many

2016-05-10 Thread Django
#24227: isinstance checks on ManyToManyField should be replaced with
field.many_to_many
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by collinanderson):

 I have a pull request here which I believe reverts the problematic parts
 of the original change. https://github.com/django/django/pull/6582

 There are 2 code branches which are basically just hacks to make the
 current ManyToManyFields work properly:
 - in forms/models.py, `model_to_dict` converts a `qs` into a list of
 `pk`s.
 - in admin/options.py, `get_changeform_initial_data` splits a string on
 commas `','`
 Custom form fields should handle this behavior themselves (if they want
 this behavior, which shouldn't be assumed).

 The other code paths are for wrapping the form field in
 `ManyToManyRawIdWidget` or other widgets, and I a custom field will want a
 custom widget.

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


Re: [Django] #18100: Deleting model instances with deferred fields don't trigger deletion signals

2016-05-10 Thread Django
#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  deferred delete  | Triage Stage:  Ready for
  signals|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #26580: Update references to the Internet message format spec

2016-05-10 Thread Django
#26580: Update references to the Internet message format spec
-+-
 Reporter:  vfaronov |Owner:  vfaronov
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"31e0314979f6aa1c66828b55dd222c32aad94e9e" 31e03149]:
 {{{
 #!CommitTicketReference repository=""
 revision="31e0314979f6aa1c66828b55dd222c32aad94e9e"
 Fixed #26580 -- Updated references to obsolete RFC 2822.

 Didn't rename django.utils.feedgenerator.rfc2822_date()
 as some external code may rely on 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/066.8ec56fec92089b7ed3212b560781fe0e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #26572: Remove email subject length truncation in AdminEmailHandler (was: AdminEmailHandler fails to honor subject length limit)

2016-05-10 Thread Django
#26572: Remove email subject length truncation in AdminEmailHandler
-+-
 Reporter:  pdewacht |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #26597: Optparse incorrect relationship between `noinput` and `interactive` in management command

2016-05-10 Thread Django
#26597: Optparse incorrect relationship between `noinput` and `interactive` in
management command
-+-
 Reporter:  JBKahn   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  migrate argparse | Triage Stage:
  command|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


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


Re: [Django] #26536: Stack overflow in template rendering when using django.template.loaders.cached.Loader

2016-05-10 Thread Django
#26536: Stack overflow in template rendering when using
django.template.loaders.cached.Loader
-+-
 Reporter:  andersroos   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"207c5b4acd410dd39bac31457dae26a0d15b8b93" 207c5b4]:
 {{{
 #!CommitTicketReference repository=""
 revision="207c5b4acd410dd39bac31457dae26a0d15b8b93"
 Fixed #26603 -- Forced lazy template names to text when computing cache
 key.

 Refs #26536.

 Thanks Sylvain Fankhauser for the very detailed report.
 }}}

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


Re: [Django] #26536: Stack overflow in template rendering when using django.template.loaders.cached.Loader

2016-05-10 Thread Django
#26536: Stack overflow in template rendering when using
django.template.loaders.cached.Loader
-+-
 Reporter:  andersroos   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"6a67dce9ccbb2533cbb3fb8d16affdf17dd1f8e7" 6a67dce]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a67dce9ccbb2533cbb3fb8d16affdf17dd1f8e7"
 [1.9.x] Fixed #26603 -- Forced lazy template names to text when computing
 cache key.

 Refs #26536.

 Thanks Sylvain Fankhauser for the very detailed report.

 Backport of 207c5b4acd410dd39bac31457dae26a0d15b8b93 from master
 }}}

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

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


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"6a67dce9ccbb2533cbb3fb8d16affdf17dd1f8e7" 6a67dce]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a67dce9ccbb2533cbb3fb8d16affdf17dd1f8e7"
 [1.9.x] Fixed #26603 -- Forced lazy template names to text when computing
 cache key.

 Refs #26536.

 Thanks Sylvain Fankhauser for the very detailed report.

 Backport of 207c5b4acd410dd39bac31457dae26a0d15b8b93 from master
 }}}

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

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


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"207c5b4acd410dd39bac31457dae26a0d15b8b93" 207c5b4]:
 {{{
 #!CommitTicketReference repository=""
 revision="207c5b4acd410dd39bac31457dae26a0d15b8b93"
 Fixed #26603 -- Forced lazy template names to text when computing cache
 key.

 Refs #26536.

 Thanks Sylvain Fankhauser for the very detailed report.
 }}}

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


Re: [Django] #18100: Deleting model instances with deferred fields don't trigger deletion signals

2016-05-10 Thread Django
#18100: Deleting model instances with deferred fields don't trigger deletion
signals
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  deferred delete  | Triage Stage:  Accepted
  signals|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:  1 => 0
 * version:  1.4 => master


Comment:

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


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.9
 Severity:  Release blocker  |   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 charettes):

 * has_patch:  0 => 1


Comment:

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


Re: [Django] #26142: Provide a way for model formsets to disallow new object creation

2016-05-10 Thread Django
#26142: Provide a way for model formsets to disallow new object creation
-+
 Reporter:  timgraham|Owner:  Mortal
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by dsanders11):

 Can you expand on that a little? Looking at the formset code, if the form
 number is less than the initial form count, it uses
 `save_existing_object`. Since `validate_max` prevents any forms above
 initial form count from being a valid formset, the only way a new object
 could be created is if `save_existing_object` could create new objects,
 which would be a bug in itself probably.

 Playing with it in Chrome, providing a blank value for the PK of one of
 the objects in the formset will cause an error when
 [https://github.com/django/django/blob/master/django/forms/models.py#L605
 trying to use to_python on the PK value] since the value is blank and an
 integer is expected. Even if that didn't fail, it would fail to find the
 object by its PK in the queryset.

 Providing a bogus value for the PK will also
 [https://github.com/django/django/blob/master/django/forms/models.py#L588
 fail to look up in the queryset] on the formset. This also occurs if you
 use a PK for an existing object that isn't in the queryset, which is good,
 otherwise you'd be able to modify objects outside the queryset which would
 be very bad.

 So, I'm not sure I see the path where new objects can be created if
 `validate_max` is set and `max_num` is 0. Doesn't mean it's not there, but
 it's not immediately obvious how that could occur.

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


Re: [Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+-
 Reporter:  sephii   |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.9
 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 charettes):

 * status:  new => assigned
 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => charettes
 * 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/064.4c564cd89ace22aa9463da4bc76e2076%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #26603: Can't use lazy objects as template names with cached loader anymore

2016-05-10 Thread Django
#26603: Can't use lazy objects as template names with cached loader anymore
-+
 Reporter:  sephii   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.9
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 It looks like commit
 
https://github.com/django/django/commit/bd145e7209a0e628cced10384bd6f62d65c0f211
 introduced a regression in Django 1.9.6. Before this commit, you could
 pass a lazy object to the {% extends %} tag and it would work just fine,
 however with Django 1.9.6 the following exception is raised:

 {{{
 Template error:
 In template /home/vagrant/ENV/local/lib/python2.7/site-
 packages/parler/templates/admin/parler/change_form.html, error at line 1
sequence item 0: expected string, __proxy__ found   1 :  {% extends
 default_change_form_template|default:"admin/change_form.html" %}
2 :
3 : {% block field_sets %}
4 : {% if language_tabs %}{% include "admin/parler/language_tabs.html"
 %}{% endif %}
5 : {{ block.super }}
6 : {% endblock %}
7 :

 Traceback:

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/core/handlers/base.py" in get_response
   174. response =
 self.process_exception_by_middleware(e, request)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/core/handlers/base.py" in get_response
   172. response = response.render()

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/response.py" in render
   160. self.content = self.rendered_content

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/response.py" in rendered_content
   137. content = template.render(context, self._request)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/backends/django.py" in render
   95. return self.template.render(context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/base.py" in render
   206. return self._render(context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/test/utils.py" in instrumented_test_render
   92. return self.nodelist.render(context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/base.py" in render
   992. bit = node.render_annotated(context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/base.py" in render_annotated
   959. return self.render(context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/loader_tags.py" in render
   151. compiled_parent = self.get_parent(context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/loader_tags.py" in get_parent
   148. return self.find_template(parent, context)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/loader_tags.py" in find_template
   128. template_name, skip=history,

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/engine.py" in find_template
   157. name, template_dirs=dirs, skip=skip,

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/loaders/cached.py" in get_template
   49. key = self.cache_key(template_name, template_dirs, skip)

 File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/template/loaders/cached.py" in cache_key
   103. return '-'.join(filter(bool, [template_name, skip_prefix,
 dirs_prefix]))

 Exception Type: TypeError at
 /en/admin/aldryn_newsblog/newsblogconfig/1/change/
 Exception Value: sequence item 0: expected string, __proxy__ found
 }}}

 You can easily reproduce the problem in a new project by using the
 following code in the urls.py file:

 {{{
 #!python
 from django.views.generic import TemplateView
 from django.utils.functional import lazy


 class TestView(TemplateView):
 template_name = 'home.html'

 def get_context_data(self, **kwargs):
 context = super(TestView, self).get_context_data(**kwargs)
 context['extended_template'] = lazy(lambda: 'base.html')
 return context

 urlpatterns = [
 url(r'^$', TestView.as_view()),
 ]
 }}}

 And create a file templates/home.html (and adapt the template dirs
 accordingly):

 {{{
 {% extends extended_template %}
 }}}

 The bug is present on master as well.

--
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

Re: [Django] #26488: migrate raises InvalidBasesError if you rename a multitable inheritance base model

2016-05-10 Thread Django
#26488: migrate raises InvalidBasesError if you rename a multitable inheritance
base model
+
 Reporter:  chrisjrn|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.9
 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 simonphilips):

 I ran into the same issue. It seems that the bases of all child classes
 are not updated in the state_forwards method of the RenameModel operation.

 This custom operation solves it, but there may be a more elegant solution:

 {{{#!python
 class RenameBaseModel(migrations.RenameModel):
 def state_forwards(self, app_label, state):
 full_old_name = ("%s.%s" % (app_label, self.old_name)).lower()
 full_new_name = ("%s.%s" % (app_label, self.new_name)).lower()

 for (app, model_name), model in state.models.items():
 if full_old_name in model.bases:
 model.bases = tuple(full_new_name if b == full_old_name
 else b
 for b in model.bases)

 super().state_forwards(app_label, state)
 }}}

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


[Django] #26602: RawSQL window functions break count()

2016-05-10 Thread Django
#26602: RawSQL window functions break count()
--+
 Reporter:  daggaz|  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:  QuerySet.extra
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I wanted to annotate my objects with a running total:

 {{{
 class A(models.Model):
 amount = models.IntegerField()
 created = models.DateTimeField(auto_now_add=True)

 qs = A.objects.annotate(total=RawSQL("SUM(amount) OVER (ORDER BY
 created)", []))
 }}}

 That works fine, and I get a running total for each object, but I cannot
 call `count()` on that queryset:
 {{{
 >>> qs.count()
 Traceback...
 ProgrammingError: window functions not allowed in GROUP BY clause
 }}}

 Using `extra()`, I can get the same annotation behaviour as well being
 able to call `count()`:
 {{{
 >>> qs = A.objects.extra(select={'total': 'SUM(amount) OVER (ORDER BY
 created)'})
 >>> qs.count()
 8
 }}}

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


Re: [Django] #1193: Write {% load i18n %} only once

2016-05-10 Thread Django
#1193: Write {% load i18n %} only once
-+--
 Reporter:  inerte@… |Owner:  adrian
 Type:  enhancement  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  minor|   Resolution:  invalid
 Keywords:  i18n, trans  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by cirosantilli):

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


Re: [Django] #17688: No m2m_changed signal sent to when referenced object is deleted

2016-05-10 Thread Django
#17688: No m2m_changed signal sent to when referenced object is deleted
-+-
 Reporter:  jblaine@…|Owner:
 |  jorgecarleitao
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jorgecarleitao):

 * needs_better_patch:  1 => 0


Comment:

 New PR with suggestions from old PR implemented:
 https://github.com/django/django/pull/6579

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


Re: [Django] #17688: No m2m_changed signal sent to when referenced object is deleted

2016-05-10 Thread Django
#17688: No m2m_changed signal sent to when referenced object is deleted
-+-
 Reporter:  jblaine@…|Owner:
 |  jorgecarleitao
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (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
-+-
Changes (by bronger):

 * cc: bronger@… (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/078.bc06dd9292c1fb7e4ca7fe2c682061d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.