Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms

[Django]

#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  forms fields media   | Triage Stage:  Ready for
  escape template jinja2 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"44a05a8a912596c44f37f050dcde85b45827b3b6" 44a05a8a]:
 {{{
 #!CommitTicketReference repository=""
 revision="44a05a8a912596c44f37f050dcde85b45827b3b6"
 [1.8.x] Fixed #24469 -- Refined escaping of Django's form elements in non-
 Django templates.

 Backport of 1f2abf784a9fe550959de242d91963b2ad6f7e9c from master
 }}}

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

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

Re: [Django] #24543: Add checks / command options for "migrations not applied" and "migrations needed"

[Django]

#24543: Add checks / command options for "migrations not applied" and 
"migrations
needed"
-+--
 Reporter:  blueyed  |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by blueyed):

 > As for me, I simply execute `migrate` as part of a deployment script.

 You are right, this is good enough and what you want to do in general.

 But what I've really meant to ask for is getting the "current migration(s)
 being applied", in case you need to rollback during deployment.

 This could be achieved manually by querying the django_migrations table
 etc, but then not that easy to handle in case of a rollback.  It might be
 useful to have a way to ask the migrations system for the current ID of
 applied migrations (`
 SELECT MAX(id) from django_migrations`) and then provide a new feature to
 rollback any later migrations (by some more complicated SQL).


 As for the 2nd wish, the `--exit` option to `makemigrations` is what I was
 looking for (added in deb6076).
 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/065.2413b3cd70a57e3f565b2fbd84e31ef2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms

[Django]

#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  forms fields media   | Triage Stage:  Ready for
  escape template jinja2 |  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:"1f2abf784a9fe550959de242d91963b2ad6f7e9c" 1f2abf7]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f2abf784a9fe550959de242d91963b2ad6f7e9c"
 Fixed #24469 -- Refined escaping of Django's form elements in non-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/065.f812660dcf675fde8e5b8a7f48b31e5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18773: Enable optional logging of invalid variable lookups

[Django]

#18773: Enable optional logging of invalid variable lookups
-+-
 Reporter:  wrigley  |Owner:
 |  CarolineSimpson
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"dc5b01ad05e50ccde688c73c2ed3334a956076b0" dc5b01a]:
 {{{
 #!CommitTicketReference repository=""
 revision="dc5b01ad05e50ccde688c73c2ed3334a956076b0"
 Fixed #18773 -- Added logging for template variable resolving

 Added a django.template logger without a default handler. Added
 logging if there is an exception while resolving variables in a
 template.
 }}}

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

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

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  claudep
 |
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 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/103.701b91b8f761001ee595000a76473f79%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  claudep
 |
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 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 claudep):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/4400

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

Re: [Django] #24546: Deletion of stale content types during migrate should show cascade

[Django]

#24546: Deletion of stale content types during migrate should show cascade
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 aaugustin):

 s/feature/footgun/ ;-)

 In case I wasn't clear enough, I consider automatic deletion acceptable
 only when there are no related objects that the cascade would delete, not
 even admin log entries.

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

Re: [Django] #24548: A testrunner test fails with unittest2 installed

[Django]

#24548: A testrunner test fails with unittest2 installed
---+--
 Reporter:  ddriddle   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.6
 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
---+--

Comment (by ddriddle):

 I did some further testing and this bug does not exist in master or 1.7.x.

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

Re: [Django] #24548: A testrunner test fails with unittest2 installed

[Django]

#24548: A testrunner test fails with unittest2 installed
---+--
 Reporter:  ddriddle   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.6
 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 timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Django 1.6 is only receiving security fixes at this point.

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

[Django] #24548: A testrunner test fails with unittest2 installed

[Django]

#24548: A testrunner test fails with unittest2 installed
---+
 Reporter:  ddriddle   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 '''RHEL6 system with Python 2.7.5'''
 {{{
 ddriddle@sdg-py27-dev:~/tmp/Django-1.6.11/tests$ python ./runtests.py
 --settings=test_sqlite -v0
 ==
 ERROR: test_dotted_test_method_vanilla_unittest
 (test_runner.test_discover_runner.DiscoverRunnerTest)
 --
 Traceback (most recent call last):
   File
 
"/services/scratch/ddriddle/tmp/Django-1.6.11/tests/test_runner/test_discover_runner.py",
 line 57, in test_dotted_test_method_vanilla_unittest
 ["test_discovery_sample.tests_sample.TestVanillaUnittest.test_sample"],
   File "/opt/cites-sdg/sdg_2015a_python27/root/usr/lib/python2.7/site-
 packages/django/test/runner.py", line 63, in build_suite
 tests = self.test_loader.loadTestsFromName(label)
   File "/opt/rh/python27/root/usr/lib/python2.7/site-
 packages/unittest2/loader.py", line 219, in loadTestsFromName
 test = obj()
 TypeError: unbound method test_sample() must be called with
 TestVanillaUnittest instance as first argument (got nothing instead)
 }}}

 '''Debian 7.8 with Python 2.7.3'''
 {{{
 ddriddle@rockband:~/src/Django-1.6.11/tests$ python ./runtests.py
 --settings=test_sqlite -v0 test_runner
 --
 Ran 31 tests in 0.770s

 OK
 ddriddle@rockband:~/src/Django-1.6.11/tests$ easy_install -U --user
 unittest2
 ddriddle@rockband:~/src/Django-1.6.11/tests$ python ./runtests.py
 --settings=test_sqlite -v0 test_runner
 ==
 ERROR: test_dotted_test_method_vanilla_unittest
 (test_runner.test_discover_runner.DiscoverRunnerTest)
 --
 Traceback (most recent call last):
   File
 "/home/ddriddle/src/Django-1.6.11/tests/test_runner/test_discover_runner.py",
 line 57, in test_dotted_test_method_vanilla_unittest
 ["test_discovery_sample.tests_sample.TestVanillaUnittest.test_sample"],
   File "/home/ddriddle/.local/lib/python2.7/site-
 packages/django/test/runner.py", line 63, in build_suite
 tests = self.test_loader.loadTestsFromName(label)
   File "/home/ddriddle/.local/lib/python2.7/site-
 packages/unittest2-1.0.1-py2.7.egg/unittest2/loader.py", line 219, in
 loadTestsFromName
 test = obj()
 TypeError: unbound method test_sample() must be called with
 TestVanillaUnittest instance as first argument (got nothing instead)

 --
 Ran 31 tests in 0.827s

 FAILED (errors=1)
 }}}

 This bug only happens when unitest2 is installed. I tested this on RHEL6
 with Python 2.7.5 and Debian 7.8 with Python 2.7.3. The Django version
 used in both cases was Django 1.6.11. This bug is related to ticket
 [ticket:20437].

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

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

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  claudep
 |
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 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
-+-

Comment (by claudep):

 Err... "1_2Fchange", of course.

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

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  claudep
 |
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 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
-+-

Comment (by claudep):

 > If I use a CharField as primary key nothing stops me from using
 "1/change" as key and we'll have exactly the same problem.

 No, "1/change" would be converted to "change_2F1" in the URL.

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

Re: [Django] #18773: Enable optional logging of invalid variable lookups

[Django]

#18773: Enable optional logging of invalid variable lookups
-+-
 Reporter:  wrigley  |Owner:
 |  CarolineSimpson
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by CarolineSimpson):

 The latest review changes are now incorporated into the patch 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 receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b9b207c8d7b9adc8de7e48e4bd3c8461%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  claudep
 |
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 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
-+-

Comment (by gertsteyn):

 The first paragraph of the Django URL dispatcher documentation says:
 "[http://www.w3.org/Provider/Style/URI Cool URIs don’t change]"...

 Do we really want to change the URL structure of every Django site out
 there for an extreme edge case like this?

 If I use a CharField as primary key nothing stops me from using "1/change"
 as key and we'll have exactly the same problem. If you insist on using a
 CharField as primary key adding some validation to exclude some "reserved"
 words is not to much of an ask.

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

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  claudep
 |
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 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 claudep):

 * owner:  nobody => claudep
 * status:  new => assigned
 * version:  1.3 => master


Comment:

 Having this relative link into `help_text` is doomed to fail. However, I
 don't see any simple workaround for now, so Tim's patch just needs 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/103.36a8fad3a66a10fd2761ec179933c4cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19259: Annotations generating inefficient SQL on PostgreSQL

[Django]

#19259: Annotations generating inefficient SQL on PostgreSQL
-+-
 Reporter:  hcarvalhoalves   |Owner:  charettes
 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
-+-
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/072.d7d233b21bad2204f386e8bb8e8aebff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24547: Errors for paths for Model relationships in other apps can be misleading / confusing

[Django]

#24547: Errors for paths for Model relationships in other apps can be 
misleading /
confusing
-+-
 Reporter:  akulakov |Owner:  akulakov
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  error message,   | Triage Stage:  Accepted
  warning|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akulakov):

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

Re: [Django] #24546: Deletion of stale content types during migrate should show cascade

[Django]

#24546: Deletion of stale content types during migrate should show cascade
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 carljm):

 I _wish_ content types were an implementation detail (or didn't exist at
 all), but unfortunately I don't think that's the case. They are a core
 part of the GenericForeignKey, which is very much a user-visible feature.
 And the ContentType model itself is documented as a user-visible feature,
 as well, so it would be entirely reasonable for people to have cascading
 FKs pointing to ContentType, and that would be within public documented
 API.

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

Re: [Django] #24546: Deletion of stale content types during migrate should show cascade

[Django]

#24546: Deletion of stale content types during migrate should show cascade
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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 aaugustin):

 The argument for deleting automatically is that content types are created
 automatically.

 They're mostly a technicality of the admin's history log, not a user-
 visible feature.

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

Re: [Django] #24244: Document contrib.admin.models.LogEntry

[Django]

#24244: Document contrib.admin.models.LogEntry
--+
 Reporter:  timgraham |Owner:
 Type:  New feature   |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * owner:  varun =>
 * status:  assigned => new


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

Re: [Django] #15590: Document how to change the path of a FileField

[Django]

#15590: Document how to change the path of a FileField
-+-
 Reporter:  simon29  |Owner:
 Type:  New feature  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  filefield| Triage Stage:  Accepted
  imagefield path filename   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  assigned => new
 * owner:  timgraham =>


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

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

Re: [Django] #15590: Document how to change the path of a FileField

[Django]

#15590: Document how to change the path of a FileField
-+-
 Reporter:  simon29  |Owner:  timgraham
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  filefield| Triage Stage:  Accepted
  imagefield path filename   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #24547: Errors for paths for Model relationships in other apps can be misleading / confusing

[Django]

#24547: Errors for paths for Model relationships in other apps can be 
misleading /
confusing
-+-
 Reporter:  akulakov |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  error message,   | Triage Stage:  Accepted
  warning|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * component:  Migrations => Database layer (models, ORM)
 * needs_tests:   => 0
 * easy:  1 => 0
 * 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/066.0d5ea3cd05e96af98e87dac6a28adbc7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24547: Errors for paths for Model relationships in other apps can be misleading / confusing

[Django]

#24547: Errors for paths for Model relationships in other apps can be 
misleading /
confusing
--+
 Reporter:  akulakov  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Migrations|Version:  master
 Severity:  Normal|   Keywords:  error message, warning
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 If a user is creating a relationship to a model in another app, it would
 be natural to use a path like: ForeignKey('app2.models.Model2'). This is
 consistent with e.g. urlconf where views are referenced like
 'myapp.views.my_view', or generally django imports that use dots to
 separate elements of a full path.

 The error you would get looks like this:
 app2.M1.f3: (fields.E300) Field defines a relation with model
 'app3.models.M1', which is either not installed, or is abstract.

 It might seem like it's not a big deal -- user just has to look at the
 docs or google for the error.

 However, in some cases it may lead to some loss of time, for example I had
 circular foreign key dependencies between models for testing and thought
 the error is due to circular references. More generally, django errors can
 result from seemingly unrelated causes so if a user starts with a firm
 assumption that a full path needs to be given, the error might lead them
 to look for all kinds of workarounds to try before coming back to the path
 format.

 It would be easy for django to check the path and, if there are more than
 one dot in path, and specifically if '.models.' is included in path, a
 hint should be shown along with the error:

 > NOTE: path should be of the form 'myapp.MyModel' and should NOT include
 the name of module containing models (which is usually 'models').

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

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

Re: [Django] #24512: 'ORA-01461: can bind a LONG value only for insert into a LONG column' error when loading data

[Django]

#24512: 'ORA-01461: can bind a LONG value only for insert into a LONG column' 
error
when loading data
-+-
 Reporter:  hadalin  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  oracle   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * Attachment "24512-test.diff" 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/065.bce6fb4448e670259e2f54e8de27cfc9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24512: 'ORA-01461: can bind a LONG value only for insert into a LONG column' error when loading data

[Django]

#24512: 'ORA-01461: can bind a LONG value only for insert into a LONG column' 
error
when loading data
-+-
 Reporter:  hadalin  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  oracle   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 The query fails when the data for the `TextField` is longer than 2000
 characters. Seems to be a duplicate of #20201 and #11487.

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

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

Re: [Django] #18914: Object tools improvements

[Django]

#18914: Object tools improvements
+
 Reporter:  mcrute  |Owner:  auvipy
 Type:  New feature |   Status:  assigned
Component:  contrib.admin   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  admin object-tools  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by auvipy):

 * owner:  nobody => auvipy
 * status:  new => assigned


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

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

Re: [Django] #16922: Add a template-based form rendering system

[Django]

#16922: Add a template-based form rendering system
+
 Reporter:  carljm  |Owner:  auvipy
 Type:  New feature |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by auvipy):

 * status:  new => assigned
 * owner:  nobody => auvipy


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

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  nobody
 |
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  closed => new
 * 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/103.a584a55257dd5ad55c90cc4f5d139479%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18773: Enable optional logging of invalid variable lookups

[Django]

#18773: Enable optional logging of invalid variable lookups
-+-
 Reporter:  wrigley  |Owner:
 |  CarolineSimpson
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Looks good, pending some minor cosmetic 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/065.42658ea11d4ceadd3df3962ebb692ee5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

[Django]

#10403: provide declarative syntax to define FormSets - including ModelFormSet 
and
InlineFormSet
-+-
 Reporter:  Koen Biermans|Owner:  auvipy
|
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
  modelformset inlineformset |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by auvipy):

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

Re: [Django] #24545: sensitive_post_parameters disclosure in csrf_exempt wrapper

[Django]

#24545: sensitive_post_parameters disclosure in csrf_exempt wrapper
-+-
 Reporter:  H0neyBadger  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
  sensitive_post_parameters  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => fixed
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 It looks like this is addressed in Django 1.8 because
 `HttpRequest.__repr__()` no longer includes GET/POST variables; see
 788fa9fffa0105d391b8fe35f2894bc5b4e29066.

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

Re: [Django] #24546: Deletion of stale content types during migrate should show cascade

[Django]

#24546: Deletion of stale content types during migrate should show cascade
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by erikr):

 * stage:  Unreviewed => Accepted


Comment:

 Yes, this would be great. I ran into this just yesterday, and indeed
 answered no because I just wasn't sure enough. I'm not sure whether
 automatic deletion if there are no other objects is good - somehow it
 seems to me that migrate should not automatically delete such data even if
 it seems harmless.

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

[Django] #24546: Deletion of stale content types during migrate should show cascade

[Django]

#24546: Deletion of stale content types during migrate should show cascade
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  master
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When deleting stale content-types, the migrate command says:

 {{{
 The following content types are stale and need to be deleted:

 auth | group_permissions

 Any objects related to these content types by a foreign key will also
 be deleted. Are you sure you want to delete these content types?
 If you're unsure, answer 'no'.

 Type 'yes' to continue, or 'no' to cancel: yes
 }}}

 At this point, the user has no way to tell whether they should answer
 'yes' or 'no'.

 Usually they will type 'no' until they get bored, say a quick prayer and
 type 'yes'.

 

 Django contains infrastructure to determine how many objects will be
 deleted.

 {{{
 >>> ct = ContentType.objects.get(app_label='auth',
 model='group_permissions')
 >>> collector = NestedObjects(using=DEFAULT_DB_ALIAS)
 >>> collector.collect([ct])
 >>> print(collector.nested())
 []
 }}}

 It would be helpful to display the list of objects that will be deleted or
 at least the number of objects.

 If the collector returns just the original object, perhaps migrate could
 even proceed with the deletion without asking.

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

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

Re: [Django] #24519: Language mismatch (word: project) between tutorial01 and tutorial02

[Django]

#24519: Language mismatch (word: project) between tutorial01 and tutorial02
--+
 Reporter:  kevinconway   |Owner:  pkatseas
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"2acf9d099d29f45c829ee0127e55b7cfdd201995" 2acf9d09]:
 {{{
 #!CommitTicketReference repository=""
 revision="2acf9d099d29f45c829ee0127e55b7cfdd201995"
 Fixed #24519 -- Clarified location of templates directory in tutorial 2.
 }}}

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

Re: [Django] #24519: Language mismatch (word: project) between tutorial01 and tutorial02

[Django]

#24519: Language mismatch (word: project) between tutorial01 and tutorial02
--+
 Reporter:  kevinconway   |Owner:  pkatseas
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"6a2f46f2381269187195a0f9165a893f54dc01a3" 6a2f46f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="6a2f46f2381269187195a0f9165a893f54dc01a3"
 [1.8.x] Fixed #24519 -- Clarified location of templates directory in
 tutorial 2.

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

Re: [Django] #24519: Language mismatch (word: project) between tutorial01 and tutorial02

[Django]

#24519: Language mismatch (word: project) between tutorial01 and tutorial02
--+
 Reporter:  kevinconway   |Owner:  pkatseas
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"da07f4b08fbf42fd71f15487d33301bb689f2655" da07f4b0]:
 {{{
 #!CommitTicketReference repository=""
 revision="da07f4b08fbf42fd71f15487d33301bb689f2655"
 [1.7.x] Fixed #24519 -- Clarified location of templates directory in
 tutorial 2.

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

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

[Django]

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  peterlauri   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by peterlauri):

 Please note that in my comment #7
 (https://code.djangoproject.com/ticket/24203#comment:7) I forgot to
 mention this was for PostgreSQL.

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

Re: [Django] #15779: admin cannot edit records with value 'add' as primary key

[Django]

#15779: admin cannot edit records with value 'add' as primary key
-+-
 Reporter:  Marwan Alsabbagh |Owner:  nobody
 |
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.3
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  1 => 0
 * severity:  Normal => Release blocker
 * stage:  Ready for checkin => Accepted


Comment:

 This broke the password change link at `/admin/auth/user/1/change/`.
 We could change the URL in `UserAdmin.get_urls()` or update the link in
 the form:
 {{{
 diff --git a/django/contrib/auth/forms.py b/django/contrib/auth/forms.py
 index 928c4c7..84fc757 100644
 --- a/django/contrib/auth/forms.py
 +++ b/django/contrib/auth/forms.py
 @@ -98,7 +98,7 @@ class UserChangeForm(forms.ModelForm):
  password = ReadOnlyPasswordHashField(label=_("Password"),
  help_text=_("Raw passwords are not stored, so there is no way to
 see "
  "this user's password, but you can change the
 password "
 -"using this form."))
 +"using this form."))

  class Meta:
  model = User
 }}}

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

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

[Django]

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  peterlauri   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration| Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by adamchainz):

 +1

 I spend a large amount of time rewriting the SQL output from django
 migrations to combine the ALTER TABLE statements for each table into one,
 just so they can pass on our production database (MySQL, 30GB, hundreds of
 millions of rows).

 Actually I normally use [http://www.percona.com/doc/percona-toolkit/2.2
 /pt-online-schema-change.html pt-online-schema-change] for tables of any
 size, since it's 0 downtime, but it's still a pain to rewrite all the SQL
 into a single ALTER.

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

Re: [Django] #23643: Have debug page show "During handling of this exception, another exception occurred.."

[Django]

#23643: Have debug page show "During handling of this exception, another 
exception
occurred.."
-+--
 Reporter:  cool-RR  |Owner:  tricoder42
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * severity:  Normal => Release blocker


Comment:

 Ran into a crash (Python 2 only) when a view raised an `IntegrityError`:
 {{{
 Traceback (most recent call last):
   File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run
 self.result = application(self.environ, self.start_response)
   File "/home/tim/code/django/django/contrib/staticfiles/handlers.py",
 line 63, in __call__
 return self.application(environ, start_response)
   File "/home/tim/code/django/django/core/handlers/wsgi.py", line 177, in
 __call__
 response = self.get_response(request)
   File "/home/tim/code/django/django/core/handlers/base.py", line 218, in
 get_response
 response = self.handle_uncaught_exception(request, resolver,
 sys.exc_info())
   File "/home/tim/code/django/django/core/handlers/base.py", line 261, in
 handle_uncaught_exception
 return debug.technical_500_response(request, *exc_info)
   File "/home/tim/code/django/django/views/debug.py", line 97, in
 technical_500_response
 html = reporter.get_traceback_html()
   File "/home/tim/code/django/django/views/debug.py", line 387, in
 get_traceback_html
 c = Context(self.get_traceback_data(), use_l10n=False)
   File "/home/tim/code/django/django/views/debug.py", line 332, in
 get_traceback_data
 frames = self.get_traceback_frames()
   File "/home/tim/code/django/django/views/debug.py", line 503, in
 get_traceback_frames
 tb = self.tb if not exceptions else exc_value.__traceback__
 AttributeError: 'IntegrityError' object has no attribute '__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/065.270c76af47a6b1e55a07a43592436b50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23771: Optimisation idea for Paginator object

[Django]

#23771: Optimisation idea for Paginator object
-+-
 Reporter:  GP89 |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  paginator| Triage Stage:  Accepted
  optimization performance   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by adamchainz):

 For the example queryset, I think just using `prefetch_related` will turn
 the joins into extra queries and they won't then appear in the count
 query.

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

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

Re: [Django] #24541: Clarify ModelFromsets handling of initial data (was: save_new_objects in ModelFromsets do not handle intitial data)

[Django]

#24541: Clarify ModelFromsets handling of initial data
--+
 Reporter:  codingjoe |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  modelformset  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * type:  Uncategorized => Cleanup/optimization
 * has_patch:  0 => 1
 * component:  Forms => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 Accepting as a documentation issue. As I said before, I don't think
 changing the behavior is acceptable given backwards compatibility. For
 example, your patch assumes that the initial data includes all fields of
 the model. Since unchanged formsets aren't validated, saving would fail
 with a database `IntegrityError` if a required field is omitted.

 Let me know if anything is unclear or if you think something additional
 should be added to the documentation. I've attached a proposed 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.55a695643186eb72e2033af7a8c28a50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24541: Clarify ModelFromsets handling of initial data

[Django]

#24541: Clarify ModelFromsets handling of initial data
--+
 Reporter:  codingjoe |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  modelformset  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * Attachment "24541.diff" 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/067.4d66302a4a747aaeb4cf813a3decad54%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

[Django]

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
---+--
 Reporter:  kalium99   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 I'm not opposed to adding some strategically placed exception handling to
 solve this but I'm afraid it isn't possible in general.

 What if two apps provide `ready()` methods, the first one successfully
 registers a signal and the second one fails? Re-running the app-loading
 process will register the signal a second time, which could create a
 variety of issues.

 If we want to do this, we must require `ready()` methods to be idempotent.

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

Re: [Django] #24538: Rendering a Jinja template with a context containing 'self' fails

[Django]

#24538: Rendering a Jinja template with a context containing 'self' fails
-+-
 Reporter:  tim_heap |Owner:  charettes
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:  wontfix
 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 aaugustin):

 * resolution:  invalid => wontfix


Comment:

 Thanks for the analysis. Indeed this appears to be the right solution.

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

Re: [Django] #24545: sensitive_post_parameters disclosure in csrf_exempt wrapper

[Django]

#24545: sensitive_post_parameters disclosure in csrf_exempt wrapper
---+
 Reporter:  H0neyBadger|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal | Resolution:
 Keywords:  sensitive_post_parameters  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
Changes (by H0neyBadger):

 * Attachment "django error report.png" added.

 error report example

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

[Django] #24545: sensitive_post_parameters disclosure in csrf_exempt wrapper

[Django]

#24545: sensitive_post_parameters disclosure in csrf_exempt wrapper
---+---
 Reporter:  H0neyBadger|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:  sensitive_post_parameters
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 Hello,
 I currently developing on 'Django Rest framework' and I try to hide some
 parameters in django error report.
 Unfortunately, the csrf_exempt method in the Traceback reveals sensitive
 post data to the admin

 I think adding request in the wrapper should do the trick

 {{{
def wrapped_view(request, *args, **kwargs):
 return view_func(request, *args, **kwargs)
 }}}



 Exception filter: SafeExceptionReporterFilter
 Decorator : @sensitive_post_parameters
 Debug = False
 Django 1.7.7
 Python 3.4.2

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

Re: [Django] #24543: Add checks / command options for "migrations not applied" and "migrations needed"

[Django]

#24543: Add checks / command options for "migrations not applied" and 
"migrations
needed"
-+--
 Reporter:  blueyed  |Owner:
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Old description:

> The `runserver` command prints a notice in case migrations are not
> applied:
>
> def check_migrations(self):
> """
> Checks to see if the set of migrations on disk matches the
> migrations in the database. Prints a warning if they don't match.
> """
> executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS])
> plan =
> executor.migration_plan(executor.loader.graph.leaf_nodes())
> if plan:
> self.stdout.write(self.style.NOTICE("\nYou have unapplied
> migrations; your app may not work properly until they are applied."))
> self.stdout.write(self.style.NOTICE("Run 'python manage.py
> migrate' to apply them.\n"))
>

> I would like to use this test during deployment.
>
> Maybe this would be appropriate for the new `--deploy` option for the
> check
> command introduced in Django 1.8?
>

> Additionally, I'd like to check if there are no migrations required,
> which I
> currently test by looking for `"No changes detected"` in `makemigrations
> --dry-run`.
>

> Even when this doesn't fit into the checks system, there should be a
> supported
> way to get theses information by means of return codes from a command.

New description:

 The `runserver` command prints a notice in case migrations are not
 applied:
 {{{
 def check_migrations(self):
 """
 Checks to see if the set of migrations on disk matches the
 migrations in the database. Prints a warning if they don't match.
 """
 executor = MigrationExecutor(connections[DEFAULT_DB_ALIAS])
 plan = executor.migration_plan(executor.loader.graph.leaf_nodes())
 if plan:
 self.stdout.write(self.style.NOTICE("\nYou have unapplied
 migrations; your app may not work properly until they are applied."))
 self.stdout.write(self.style.NOTICE("Run 'python manage.py
 migrate' to apply them.\n"))
 }}}

 I would like to use this test during deployment.

 Maybe this would be appropriate for the new `--deploy` option for the
 check
 command introduced in Django 1.8?


 Additionally, I'd like to check if there are no migrations required, which
 I
 currently test by looking for `"No changes detected"` in `makemigrations
 --dry-run`.


 Even when this doesn't fit into the checks system, there should be a
 supported
 way to get theses information by means of return codes from a command.

--

Comment (by timgraham):

 As for me, I simply execute `migrate` as part of a deployment script. If
 there aren't any migrations to apply, it's just a no-op. Could you
 elaborate on your use case for needing to know if migrations are applied
 or not? Currently, `check --deploy` is simply a static analysis of a
 settings file. The check you proposed would require the ability to connect
 to the production database which might not be possible from a development
 machine.

 Regarding the second point, `makemigrations` gained an
 [https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-
 option---exit --exit] option in 1.8 which does what you describe.

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

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

Re: [Django] #24499: Drop support for PostGIS 1.5

[Django]

#24499: Drop support for PostGIS 1.5
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * keywords:  2.0 =>
 * stage:  Someday/Maybe => 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/067.33a32d0c0604b270f435b3f43bd71ea4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24544: core.files.images.get_image_dimensions broken on some valid PNG images

[Django]

#24544: core.files.images.get_image_dimensions broken on some valid PNG images
--+
 Reporter:  artscoop  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  File uploads/storage  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  PIL   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * 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/066.a1e4a80d1c2dc723a16d2b7567db4861%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24544: core.files.images.get_image_dimensions broken on some valid PNG images

[Django]

#24544: core.files.images.get_image_dimensions broken on some valid PNG images
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  File |  Version:  1.7
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  PIL  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by phalt):

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

Re: [Django] #24541: save_new_objects in ModelFromsets do not handle intitial data

[Django]

#24541: save_new_objects in ModelFromsets do not handle intitial data
---+--
 Reporter:  codingjoe  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  modelformset   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by codingjoe):

 I know that I can make it work, I'm just asking myself the questions if it
 shouldn't just work out of the box.

 A ModelFormSet would be the only model, that has a different behavior
 regarding initial data and therefore also doesn't work with the generic
 FormView.

 This really doesn't sound like a feature, it's a bug.

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

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

Re: [Django] #24544: core.files.images.get_image_dimensions broken on some valid PNG images

[Django]

#24544: core.files.images.get_image_dimensions broken on some valid PNG images
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  File |  Version:  1.7
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  PIL  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by artscoop):

 Pull request made here: https://github.com/django/django/pull/4398

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

Re: [Django] #24544: core.files.images.get_image_dimensions broken on some valid PNG images

[Django]

#24544: core.files.images.get_image_dimensions broken on some valid PNG images
-+-
 Reporter:  artscoop |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  File |  Version:  1.7
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  PIL  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by artscoop):

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


Old description:

> Hi,
> second time I find a bug in the same function. Here, the function failed
> (exception raised and not caught) on a valid PNG file (this image:
> https://mega.co.nz/#!W0tXzBAK!iLprbqkVWFAzfcn2GUDRGHiH8Pxyi4DxCQi580shcec).
> The error raised by PIL is a `struct.error`, which should be expected but
> is not caught by the chunk feeder loop.
>
> The feeder knows this
>
> {{{
> except zlib.error as e:
> # ignore zlib complaining on truncated stream, just feed
> more
> # data to parser (ticket #19457).
> if e.args[0].startswith("Error -5"):
> pass
> else:
> raise
> }}}
>
> but does not know this
>
> {{{
> from struct import error
> ...
>
> except struct.error:
> pass
> }}}

New description:

 Hi,
 second time I find a bug in the same function. Here, the function failed
 (exception raised and not caught) on a valid PNG file (this image:
 https://mega.co.nz/#!W0tXzBAK!iLprbqkVWFAzfcn2GUDRGHiH8Pxyi4DxCQi580shcec).
 The error raised by PIL is a `struct.error`, which should be expected but
 is not caught by the chunk feeder loop.

 The feeder knows this

 {{{
 except zlib.error as e:
 # ignore zlib complaining on truncated stream, just feed
 more
 # data to parser (ticket #19457).
 if e.args[0].startswith("Error -5"):
 pass
 else:
 raise
 }}}

 but does not know this

 {{{
 from struct import error
 ...

 except struct.error:
 pass
 }}}

 when you catch the proper exception, the file header fed to the parser
 becomes correct starting at offset 9214.
 The good news is, it does not need tests.

--

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

Re: [Django] #24544: core.files.images.get_image_dimensions broken on some valid PNG images

[Django]

#24544: core.files.images.get_image_dimensions broken on some valid PNG images
--+
 Reporter:  artscoop  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  File uploads/storage  |Version:  1.7
 Severity:  Normal| Resolution:
 Keywords:  PIL   |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by artscoop):

 * Attachment "b.png" added.

 Valid but faulty image

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

[Django] #24544: core.files.images.get_image_dimensions broken on some valid PNG images

[Django]

#24544: core.files.images.get_image_dimensions broken on some valid PNG images
--+
 Reporter:  artscoop  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  File uploads/storage  |Version:  1.7
 Severity:  Normal|   Keywords:  PIL
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi,
 second time I find a bug in the same function. Here, the function failed
 (exception raised and not caught) on a valid PNG file (this image:
 https://mega.co.nz/#!W0tXzBAK!iLprbqkVWFAzfcn2GUDRGHiH8Pxyi4DxCQi580shcec).
 The error raised by PIL is a `struct.error`, which should be expected but
 is not caught by the chunk feeder loop.

 The feeder knows this

 {{{
 except zlib.error as e:
 # ignore zlib complaining on truncated stream, just feed
 more
 # data to parser (ticket #19457).
 if e.args[0].startswith("Error -5"):
 pass
 else:
 raise
 }}}

 but does not know this

 {{{
 from struct import error
 ...

 except struct.error:
 pass
 }}}

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

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