Re: [Django] #18748: Remove dupe-avoidance logic from the ORM

[Django]

#18748: Remove dupe-avoidance logic from the ORM
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 I managed to miss the "Fixed #18748" from the commit message... So, fixed
 in [68847135bc9acb2c51c2d36797d0a85395f0cd35].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 688471: Removed dupe_avoidance from sql/query and sql/comp...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 68847135bc9acb2c51c2d36797d0a85395f0cd35
  
https://github.com/django/django/commit/68847135bc9acb2c51c2d36797d0a85395f0cd35
  Author: Anssi Kääriäinen 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/db/models/fields/related.py
M django/db/models/options.py
M django/db/models/sql/compiler.py
M django/db/models/sql/constants.py
M django/db/models/sql/query.py
M tests/regressiontests/queries/tests.py

  Log Message:
  ---
  Removed dupe_avoidance from sql/query and sql/compiler.py

The dupe avoidance logic was removed as it doesn't seem to do anything,
it is complicated, and it has nearly zero documentation.

The removal of dupe_avoidance allowed for refactoring of both the
implementation and signature of Query.join(). This refactoring cascades
again to some other parts. The most significant of them is the changes
in qs.combine(), and compiler.select_related_descent().



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19217: Make it Simple

[Django]

#19217: Make it Simple
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:  invalid
 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 ptone):

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


Comment:

 I'm sorry the docs didn't work out for you.  We always welcome specific
 issues and potential improvements.  However in this case there is nothing
 specific or actionable other than a vague "these docs are bad - please
 improve them".  Without something specific, this isn't a valid ticket.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] d55c54: The timeout variable wasn't defined, which was a l...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d55c54a5da241e294c1162a19a07ab3f59e58dc7
  
https://github.com/django/django/commit/d55c54a5da241e294c1162a19a07ab3f59e58dc7
  Author: Brent O'Connor 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M docs/topics/testing.txt

  Log Message:
  ---
  The timeout variable wasn't defined, which was a little confusing.


  Commit: 9bf0eedba581ba66b8b8391a7e611d6cf7ef5448
  
https://github.com/django/django/commit/9bf0eedba581ba66b8b8391a7e611d6cf7ef5448
  Author: Preston Holmes 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M docs/topics/testing.txt

  Log Message:
  ---
  Merge pull request #481 from epicserve/testing_docs_update

Added timeout local to selenium sample test

The timeout variable wasn't defined, which was a little confusing.


Compare: https://github.com/django/django/compare/08cf54990ae1...9bf0eedba581

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19217: Make it Simple

[Django]

#19217: Make it Simple
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I know django has made things simple and I like the first tutorial also
 but the moment I try to explore about the static files I start wasting my
 time more and more..https://docs.djangoproject.com/en/dev/howto/static-
 files/ - This doc doesn't help at all - I may be dumb but really this is
 not what user needs. Its haphazard and confuses the user a lot. It should
 be simple step by step kind of thing. Too many questions asked on
 stackoverflow.com website about django static files proves that this doc
 is actually not helping. I went through some 10 questions on Django static
 files over that site and read the docs but it doesn't help. People are
 still asking questions on the same thing again and again.

 I am still unable to use a simple css file for my first flatpage. May be
 it will take some 2-3 days before I figure it out - what exactly the doc
 is trying to say - may be not and I have to ask someone. Will see.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5373: Field label for a ForeignKey not translated

[Django]

#5373: Field label for a ForeignKey not translated
-+-
 Reporter:  Szilveszter Farkas   |Owner:  Fandekasp
   |   Status:  closed
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:  wontfix
  Internationalization   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  i18n foreignkey  |  Patch needs improvement:  1
  field label|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by datakid):

 I also note that


 {{{
 class Citation(models.Model):
book = ForeignKey(Book, verbose_name=Book._meta.verbose_name_plural)
 }}}

 works but

 {{{
 class Citation(models.Model):
book = ForeignKey(Book,
 verbose_name_plural=Book._meta.verbose_name_plural)
 }}}

 doesn't.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5373: Field label for a ForeignKey not translated

[Django]

#5373: Field label for a ForeignKey not translated
-+-
 Reporter:  Szilveszter Farkas   |Owner:  Fandekasp
   |   Status:  closed
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:  wontfix
  Internationalization   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  i18n foreignkey  |  Patch needs improvement:  1
  field label|UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by datakid):

 I've just noticed that a somewhat similar error is occurring re:
 verbose_name on Object being a FK in a model. ie, the "not
 translated"/Internationalisation here is secondary to the problem.

 This should be documented - in the i18n docs and the FK docs I think.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19216: Use user level installation rather than system level in advanced tutorial

[Django]

#19216: Use user level installation rather than system level in advanced 
tutorial
---+
 Reporter:  ncoghlan   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The new advanced tutorial uses system level installation for simplicity
 in:
 https://docs.djangoproject.com/en/dev/intro/reusable-apps/#using-your-own-
 package

 This requires several of the steps to be run with administrator
 privileges.

 It should be possible to avoid this (and make the section even simpler)
 just by changing the installation command in this section to:

 python setup.py install --user

 This obviously won't work in versions prior to 2.6, but there's no reason
 a beginner would be using such an old version (and if they are, lack of
 per-user package support is going to be the least of their problems)

 Note that per-user installations can still affect the behaviour of system
 tools run as that user, so virtualenv is still the more robust solution.
 However, per-user installs also have a *lot* recommend them over system
 level installs (such as being usable on systems where you don't have admin
 access, not running downloaded code with admin privileges, as well as not
 affecting the behaviour seen by system services and other users of the
 machine).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19214: AdminEmailHandler is synchronous.

[Django]

#19214: AdminEmailHandler is synchronous.
---+
 Reporter:  tdhutt@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  AdminEmailHandler  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by russellm):

 Yeah... I'm a *HUGE* -1 on this.

 Using threads like this is *monunmentally* bad idea. Consider - in the
 pathological case, your webserver will start up a clean environment for
 every request. If the thread is allowed to run disconnected, that means
 you'll have a thread running that you *hope* finishes. Alternatively,
 you'll need to join the thread before the request finishes, which means
 you'll end up with the same type of lockup behaviour (although, depending
 on how it's implemented, it might not be observable to the end-user -- it
 will just manifest as resource starvation due to an unavailable process on
 the web server.

 In practice. your webserver won't be configured like this; but in
 practice, you'll also usually have a 'maximum requests served' limit on a
 process, so you'll never know if you're dealing with the "last" request
 that a particular process will be handling. You'll end up with the same
 problem, just harder to peg down.

 We have an existing framework for fixing latency problems with sending
 mail -- it's the mail backend API. The default mail backend is dumb and
 synchronous. It's a reasonable and default that will work everywhere (once
 configured) and on low traffic sites will cause no problems. For higher
 traffic sites, there are plenty of implementations out there that are non-
 blocking. We don't fix *anything* by making one specific usage threaded --
 or even the mail API itself -- threaded and/or asynchronous while still
 being bound to the request/response cycle.

 I'm in favor of wontfixing this; or, at the very most, documenting the
 synchronous limitations of the default mail handler 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18856: avoid set_language redirect to different host

[Django]

#18856: avoid set_language redirect to different host
-+-
 Reporter:  Gunnar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  set_language | Triage Stage:  Accepted
  redirect infinite loop |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by apollo13):

 * severity:  Normal => Release blocker
 * cc: apollo13 (added)
 * needs_better_patch:  0 => 1
 * component:  Internationalization => Uncategorized
 * version:  1.4 => master
 * stage:  Ready for checkin => Accepted


Comment:

 We also need to check the rest of the codebase for similar issues and
 factor this stuff out into a utility function like:
 {{{
 def safe_redirect(request, redirect_to):
   # check redirect_to against request.get_host() or so here...
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19215: ImageField's “Currently” and “Clear” Sometimes Don't Appear

[Django]

#19215: ImageField's “Currently” and “Clear” Sometimes Don't Appear
-+
 Reporter:  nrogers64@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  ImageField   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+
Changes (by carljm):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for filing the report!

 I've verified this behavior, and I think it is less-than-optimal. The path
 to fixing it isn't entirely clear, though.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19215: ImageField's “Currently” and “Clear” Sometimes Don't Appear

[Django]

#19215: ImageField's “Currently” and “Clear” Sometimes Don't Appear
-+
 Reporter:  nrogers64@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.4
 Severity:  Normal   |   Keywords:  ImageField
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  1
-+
 I have found scenarios where an ImageField's “Currently” and “Clear”
 widgets don't appear. Here are the instructions to reproduce the
 scenarios:

 Create an app called "imagefield_bug" and paste this in its "models.py"
 file:


 {{{
 from django.db import models


 class ImageFieldBug(models.Model):
 required_text_field = models.CharField(max_length=100)
 optional_image = models.ImageField(upload_to='images/', blank=True,
 null=True)

 def __unicode__(self):
 return self.required_text_field

 }}}


 Add the "imagefield_bug" app to your project's INSTALLED_APPS. Make sure
 "django.contrib.admin" is also in INSTALLED_APPS while you're at it.

 Make sure the admin lines in "urls.py" are uncommented.

 Run these commands:


 {{{
 printf "from django.contrib import admin\nfrom models import
 ImageFieldBug\n\nadmin.site.register(ImageFieldBug)\n" >
 imagefield_bug/admin.py

 python manage.py syncdb

 python manage.py runserver
 }}}


 Go to the following URL, log in, fill out both fields correctly, and click
 "Save and continue editing":

 http://127.0.0.1:8000/admin/imagefield_bug/imagefieldbug/add/

 Now you should see the "Currently" and "Clear" widgets. Choose a non-image
 to upload and then click "Save". Now the "Currently" and "Clear" widgets
 are gone, potentially misleading the user into thinking the original image
 is gone forever.

 Now click your browser's "Back" button, refresh the page, blank out the
 "Required text field" field, and either check the "Clear" checkbox or
 choose a valid image to upload. After that, click "Save". Again, the
 "Currently" and "Clear" widgets will be gone.

 See [https://groups.google.com/d/topic/django-
 developers/3lpFZ380dzQ/discussion this django-developers discussion] for
 more information.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16671: 5th tutorial on turning Polls into a reusable app

[Django]

#16671: 5th tutorial on turning Polls into a reusable app
---+
 Reporter:  stumbles   |Owner:  ben@…
 Type:  New feature|   Status:  closed
Component:  Documentation  |  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
---+

Comment (by Tim Graham ):

 In [changeset:"5c7406b236b641ac1802d1471f04b27166909121"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5c7406b236b641ac1802d1471f04b27166909121"
 [1.5.X] Fixed #16671 - Added a tutorial on reuseable apps

 Thank-you Katie Miller and Ben Sturmfels for the initial draft,
 as well as Russ and Carl for the reviews.

 Backport of 08cf54990a 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5c7406: [1.5.X] Fixed #16671 - Added a tutorial on reuseab...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 5c7406b236b641ac1802d1471f04b27166909121
  
https://github.com/django/django/commit/5c7406b236b641ac1802d1471f04b27166909121
  Author: Tim Graham 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M AUTHORS
M docs/index.txt
M docs/intro/index.txt
A docs/intro/reusable-apps.txt
M docs/intro/tutorial03.txt
M docs/intro/tutorial04.txt

  Log Message:
  ---
  [1.5.X] Fixed #16671 - Added a tutorial on reuseable apps

Thank-you Katie Miller and Ben Sturmfels for the initial draft,
as well as Russ and Carl for the reviews.

Backport of 08cf54990a from master



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16671: 5th tutorial on turning Polls into a reusable app

[Django]

#16671: 5th tutorial on turning Polls into a reusable app
---+
 Reporter:  stumbles   |Owner:  ben@…
 Type:  New feature|   Status:  closed
Component:  Documentation  |  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:"08cf54990ae112083b159aa4e263c1f64f396f39"]:
 {{{
 #!CommitTicketReference repository=""
 revision="08cf54990ae112083b159aa4e263c1f64f396f39"
 Fixed #16671 - Added a tutorial on reuseable apps

 Thank-you Katie Miller and Ben Sturmfels for the initial draft,
 as well as Russ and Carl for the reviews.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 08cf54: Fixed #16671 - Added a tutorial on reuseable apps

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 08cf54990ae112083b159aa4e263c1f64f396f39
  
https://github.com/django/django/commit/08cf54990ae112083b159aa4e263c1f64f396f39
  Author: Tim Graham 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M AUTHORS
M docs/index.txt
M docs/intro/index.txt
A docs/intro/reusable-apps.txt
M docs/intro/tutorial03.txt
M docs/intro/tutorial04.txt

  Log Message:
  ---
  Fixed #16671 - Added a tutorial on reuseable apps

Thank-you Katie Miller and Ben Sturmfels for the initial draft,
as well as Russ and Carl for the reviews.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9c4dde: [1.5.x] Fixed #19174 -- Fixed capitalization error...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 9c4ddea8e6cb5bd06b4ba9b53df5fb29f964a8ee
  
https://github.com/django/django/commit/9c4ddea8e6cb5bd06b4ba9b53df5fb29f964a8ee
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/conf/locale/__init__.py

  Log Message:
  ---
  [1.5.x] Fixed #19174 -- Fixed capitalization errors in LANG_INFO

Thanks waldeinburg for the report.
Backport of 2f035a9 from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19174: Some capitalization errors in django.conf.locale.LANG_INFO

[Django]

#19174: Some capitalization errors in django.conf.locale.LANG_INFO
--+
 Reporter:  waldeinburg   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:  language, spelling| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Claude Paroz ):

 In [changeset:"9c4ddea8e6cb5bd06b4ba9b53df5fb29f964a8ee"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9c4ddea8e6cb5bd06b4ba9b53df5fb29f964a8ee"
 [1.5.x] Fixed #19174 -- Fixed capitalization errors in LANG_INFO

 Thanks waldeinburg for the report.
 Backport of 2f035a9 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19174: Some capitalization errors in django.conf.locale.LANG_INFO

[Django]

#19174: Some capitalization errors in django.conf.locale.LANG_INFO
--+
 Reporter:  waldeinburg   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:  language, spelling| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"2f035a9723d62a63027df4c779c665e8191dd95b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2f035a9723d62a63027df4c779c665e8191dd95b"
 Fixed #19174 -- Fixed capitalization errors in LANG_INFO

 Thanks waldeinburg 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 2f035a: Fixed #19174 -- Fixed capitalization errors in LAN...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 2f035a9723d62a63027df4c779c665e8191dd95b
  
https://github.com/django/django/commit/2f035a9723d62a63027df4c779c665e8191dd95b
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/conf/locale/__init__.py

  Log Message:
  ---
  Fixed #19174 -- Fixed capitalization errors in LANG_INFO

Thanks waldeinburg for the report.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5725: Inspectdb makes too long CharFields

[Django]

#5725: Inspectdb makes too long CharFields
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  introspection mysql  |  checkin
  inspectdb  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 This was not backported to 1.4, so please test with current code (1.5alpha
 or 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 Claude Paroz ):

 In [changeset:"2f9f211da867d872a0d3576c3ac515d74f5798cd"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2f9f211da867d872a0d3576c3ac515d74f5798cd"
 [1.5.x] Prevented file_upload tests to leave files behind

 Refs #19206.
 Backport of 73245b3 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 2f9f21: [1.5.x] Prevented file_upload tests to leave files...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 2f9f211da867d872a0d3576c3ac515d74f5798cd
  
https://github.com/django/django/commit/2f9f211da867d872a0d3576c3ac515d74f5798cd
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M tests/regressiontests/file_uploads/models.py
M tests/regressiontests/file_uploads/tests.py
M tests/regressiontests/file_uploads/views.py

  Log Message:
  ---
  [1.5.x] Prevented file_upload tests to leave files behind

Refs #19206.
Backport of 73245b3 from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19206: Stale tmp files after running the testsuite.

[Django]

#19206: Stale tmp files after running the testsuite.
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 Claude Paroz ):

 In [changeset:"73245b3285f63694d2c63c9b197165dc6d9cfd4e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="73245b3285f63694d2c63c9b197165dc6d9cfd4e"
 Prevented file_upload tests to leave files behind

 Refs #19206.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 73245b: Prevented file_upload tests to leave files behind

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 73245b3285f63694d2c63c9b197165dc6d9cfd4e
  
https://github.com/django/django/commit/73245b3285f63694d2c63c9b197165dc6d9cfd4e
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M tests/regressiontests/file_uploads/models.py
M tests/regressiontests/file_uploads/tests.py
M tests/regressiontests/file_uploads/views.py

  Log Message:
  ---
  Prevented file_upload tests to leave files behind

Refs #19206.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17744: override_settings has no effect on FileSystemStorage()

[Django]

#17744: override_settings has no effect on FileSystemStorage()
-+-
 Reporter:  mvt  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  File |  Version:
  uploads/storage|  1.4-beta-1
 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
-+-

Comment (by Claude Paroz ):

 In [changeset:"a24ffa52d02998f5082fbc5a461ccdc8004db4a6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a24ffa52d02998f5082fbc5a461ccdc8004db4a6"
 [1.5.x] Fixed #17744 -- Reset default file storage with setting_changed
 signal

 Backport of 9a0285134 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] a24ffa: [1.5.x] Fixed #17744 -- Reset default file storage...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: a24ffa52d02998f5082fbc5a461ccdc8004db4a6
  
https://github.com/django/django/commit/a24ffa52d02998f5082fbc5a461ccdc8004db4a6
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/test/signals.py
M docs/topics/testing.txt
M tests/regressiontests/staticfiles_tests/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #17744 -- Reset default file storage with setting_changed signal

Backport of 9a0285134 from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17744: override_settings has no effect on FileSystemStorage()

[Django]

#17744: override_settings has no effect on FileSystemStorage()
-+-
 Reporter:  mvt  |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  File |  Version:
  uploads/storage|  1.4-beta-1
 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 Claude Paroz ):

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


Comment:

 In [changeset:"9a02851340c5c30b8e2c174783cd86d5cab7ab81"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9a02851340c5c30b8e2c174783cd86d5cab7ab81"
 Fixed #17744 -- Reset default file storage with setting_changed signal
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9a0285: Fixed #17744 -- Reset default file storage with se...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9a02851340c5c30b8e2c174783cd86d5cab7ab81
  
https://github.com/django/django/commit/9a02851340c5c30b8e2c174783cd86d5cab7ab81
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/test/signals.py
M docs/topics/testing.txt
M tests/regressiontests/staticfiles_tests/tests.py

  Log Message:
  ---
  Fixed #17744 -- Reset default file storage with setting_changed signal



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15661: LogEntry objects have no unicode method

[Django]

#15661: LogEntry objects have no unicode method
-+-
 Reporter:  Keryn Knight |Owner:  ShawnMilo
|   Status:  reopened
 Type:  New feature  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  logentry unicode |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by vsf):

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


Comment:

 I've the same problem but I don't have custom action_flags. That solution
 is no working for me.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19214: AdminEmailHandler is synchronous.

[Django]

#19214: AdminEmailHandler is synchronous.
---+
 Reporter:  tdhutt@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  AdminEmailHandler  | 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):

 I'm very wary of spawning threads in request handlers. It will work in
 trivial cases but I'm not sure application servers handle this very well
 under load.

 lrekucki's proposal is interesting — and can be implemented as a
 [https://docs.djangoproject.com/en/dev/topics/email/#defining-a-custom-
 email-backend custom email backend].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17083: sessions.backends.cache does not allow non-default cache to be configured

[Django]

#17083: sessions.backends.cache does not allow non-default cache to be 
configured
-+-
 Reporter:  charles@…|Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17083: sessions.backends.cache does not allow non-default cache to be configured

[Django]

#17083: sessions.backends.cache does not allow non-default cache to be 
configured
-+-
 Reporter:  charles@…|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17083: sessions.backends.cache does not allow non-default cache to be configured

[Django]

#17083: sessions.backends.cache does not allow non-default cache to be 
configured
--+
 Reporter:  charles@… |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 For consistency with other parts of Django, I'd prefer adding a setting
 (yeah...) rather than hardcoding a cache name.

 Pull request: https://github.com/django/django/pull/479

 (I forgot to add a comment in the release notes.)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10811: Assigning unsaved model to a ForeignKey leads to silent failures

[Django]

#10811: Assigning unsaved model to a ForeignKey leads to silent failures
-+-
 Reporter:  Glenn|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


Comment:

 #11811 should be fixed in the same fashion at the same time.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10811: Assigning unsaved model to a ForeignKey leads to silent failures

[Django]

#10811: Assigning unsaved model to a ForeignKey leads to silent failures
-+-
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 I prefer failing early and loudly, by raising an exception when an unsaved
 object is assigned to a related field.

 I could listen to an argument for trying to re-fetch the pk from the
 cached related instance in save(), but that feels like action-
 at-a-distance: the actual problem usually happened earlier.

 Automatically saving related objects is too magic; I'm sure it would be
 considered unexpected and undesirable in some circumstances.

 

 This is a bug that may lead to data loss ; it's pretty bad. Given that it
 hasn't been fixed in three years I'm strongly in favor of the simplest
 solution, raising an exception.

 It would also be consistent with 3190abcd75b1fcd660353da4001885ef82cbc596
 — a fix for the same problem for reverse one-to-one relations.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14615: Related objects manager returns related objects with null FKs for unsaved instances

[Django]

#14615: Related objects manager returns related objects with null FKs for 
unsaved
instances
-+-
 Reporter:  tonnzor  |Owner:
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Given Luke's last comment, I believe this is a duplicate #18153 which I
 fixed in 3190abcd75b1fcd660353da4001885ef82cbc596.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5419: Add a model fuzz testing method to the test framework

[Django]

#5419: Add a model fuzz testing method to the test framework
---+
 Reporter:  adrian |Owner:  kkubasik
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  feature| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by d1ffuz0r):

 * needs_tests:  1 => 0


Comment:

 patch has been updated and tested in python 2.7.3/3.3.0. also added some
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 43d7ce: Added release notes for 1.6.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 43d7cee86e05dc267d66c3a308746fc1ac58271e
  
https://github.com/django/django/commit/43d7cee86e05dc267d66c3a308746fc1ac58271e
  Author: Aymeric Augustin 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
A docs/releases/1.6.txt
M docs/releases/index.txt

  Log Message:
  ---
  Added release notes for 1.6.

Since 1.5 is feature-frozen, we need them to document new features.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11811: No error raised on update(foreignkey=unsavedobject) on nullable fk

[Django]

#11811: No error raised on update(foreignkey=unsavedobject) on nullable fk
-+-
 Reporter:  Afief|Owner:  ashearer
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Related to #10811.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5725: Inspectdb makes too long CharFields

[Django]

#5725: Inspectdb makes too long CharFields
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  introspection mysql  |  checkin
  inspectdb  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mark0978):

 Looks like this one is back in 1.4.2

 A similar problem happens with mysql 5.5 where the size is 3x greater than
 that specified, given the SQL:

 CREATE TABLE `primaryfields` (
   `fpost` int(11) NOT NULL,
   `index1911` char(36) DEFAULT NULL,
   `ssn` char(11) DEFAULT NULL,
   `middleinitial` char(1) DEFAULT NULL,
   `firstname` char(30) DEFAULT NULL,
   `lastname` char(30) DEFAULT NULL,
   `employeeid` char(10) DEFAULT NULL,
   PRIMARY KEY (`fpost`),
   CONSTRAINT `primaryfields_ibfk_1` FOREIGN KEY (`fpost`) REFERENCES
 `filenames` (`fpost`)
 ) ENGINE=InnoDB DEFAULT CHARSET='''latin1''' |

 You get the Python:

 class Primaryfields(models.Model):
 fpost = models.ForeignKey(Filenames, primary_key=True,
 db_column='fpost')
 index1911 = models.CharField(max_length=108, blank=True)
 ssn = models.CharField(max_length=33, blank=True)
 middleinitial = models.CharField(max_length=3, blank=True)
 firstname = models.CharField(max_length=90, blank=True)
 lastname = models.CharField(max_length=90, blank=True)
 employeeid = models.CharField(max_length=30, blank=True)
 class Meta:
 db_table = u'primaryfields'

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17202: Inspectdb produces incorrect max_length for NVARCHAR2 columns with Oracle

[Django]

#17202: Inspectdb produces incorrect max_length for NVARCHAR2 columns with 
Oracle
-+-
 Reporter:  rodolfo.3+django@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  inspectdb oracle |  Needs documentation:  0
  max_length |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by mark0978):

 A similar problem happens with mysql 5.5.28CE on linux where the size is
 3x greater than that specified, given the SQL:

 CREATE TABLE `primaryfields` (
   `fpost` int(11) NOT NULL,
   `index1911` char(36) DEFAULT NULL,
   `ssn` char(11) DEFAULT NULL,
   `middleinitial` char(1) DEFAULT NULL,
   `firstname` char(30) DEFAULT NULL,
   `lastname` char(30) DEFAULT NULL,
   `employeeid` char(10) DEFAULT NULL,
   PRIMARY KEY (`fpost`),
   CONSTRAINT `primaryfields_ibfk_1` FOREIGN KEY (`fpost`) REFERENCES
 `filenames` (`fpost`)
 ) ENGINE=InnoDB DEFAULT CHARSET='''latin1''' |

 You get the Python:

 class Primaryfields(models.Model):
 fpost = models.ForeignKey(Filenames, primary_key=True,
 db_column='fpost')
 index1911 = models.CharField(max_length=108, blank=True)
 ssn = models.CharField(max_length=33, blank=True)
 middleinitial = models.CharField(max_length=3, blank=True)
 firstname = models.CharField(max_length=90, blank=True)
 lastname = models.CharField(max_length=90, blank=True)
 employeeid = models.CharField(max_length=30, blank=True)
 class Meta:
 db_table = u'primaryfields'

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19211: Tutorial must be updated for Python 3

[Django]

#19211: Tutorial must be updated for Python 3
-+-
 Reporter:  adj7388@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Documentation|  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  python3 unicode str  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> When using Python 3.3 and 1.5-alpha-1 (note: underlined unicode() and
> str() below should have double underscores)
>
> See this section of the tutorial "Why __unicode__() and not __str__()?":
> https://docs.djangoproject.com/en/1.5/intro/tutorial01/#playing-with-the-
> api
>
> This section of the tutorial says to add __unicode__() method to your
> Model classes so that admin and shell display useful strings. This is
> correct for Python 2.x, but breaks object display under Python 3.3.
> __str__() should be used instead of __unicode__(). Tutorial probably
> needs a sidebar or other additional information for users using Python
> 3.x.

New description:

 When using Python 3.3 and 1.5-alpha-1.

 See this section of the tutorial "Why `__unicode__()` and not
 `__str__()`?": https://docs.djangoproject.com/en/1.5/intro/tutorial01
 /#playing-with-the-api

 This section of the tutorial says to add `__unicode__()` method to your
 Model classes so that admin and shell display useful strings. This is
 correct for Python 2.x, but breaks object display under Python 3.3.
 `__str__()` should be used instead of `__unicode__()`. Tutorial probably
 needs a sidebar or other additional information for users using Python
 3.x.

--

Comment (by lukeplant):

 Description fixed - you can include literal code by enclosing in
 backticks, as described on WikiFormatting.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19214: AdminEmailHandler is synchronous.

[Django]

#19214: AdminEmailHandler is synchronous.
---+
 Reporter:  tdhutt@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  AdminEmailHandler  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by lrekucki):

 Making it async will only hide the fact that it's slow. Wouldn't it be
 better to keep the MTA connection open (or have a pool of open
 connections), as creating the connection is what most likely slows this
 down? I have a feeling this is a solution on a wrong level - isn't this
 something that is done in the email backend? And spawning a new thread on
 each call to emit() looks at least wasteful if not dangerous.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14952: New find_commands(management_dir) to support .pyc and .pyo

[Django]

#14952: New find_commands(management_dir) to support .pyc and .pyo
---+--
 Reporter:  lgx@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  Version:  1.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  find_commands  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by danielgoncalves):

 Thank you @russellm,
 Since your response I read (and re-read) the PEP 3147 carefully and,
 although they will continue to support source-less distributions, we will
 be looking for a better way to distribute our code. You gave me a lot of
 good advices.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19189: FormWizard done method can't revisit forms

[Django]

#19189: FormWizard done method can't revisit forms
---+--
 Reporter:  kenth  |Owner:  nobody
 Type:  New feature|   Status:  reopened
Component:  contrib.formtools  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kenth):

 * status:  closed => reopened
 * has_patch:  0 => 1
 * resolution:  needsinfo =>


Comment:

 Thanks for reviewing the ticket. I found the need to perform
 "revalidation" in the `done` step in an e-commerce project incorporating
 validation using stripe.com which separates validation (performed in the
 form's `clean` method) and charging (which I perform in `done`). However,
 I think the problem is more general than this specific case.

 I had rejected performing a 'charge' in the clean of a confirmation step,
 instead preferring the `done` method for two reasons:

 1. The wizard validates each form at least twice (when the form is
 initially validated and again in `render_done`). To ensure an action is
 performed only once, the `clean` method needs to leave a token to not
 repeat the action. This can be fragile.

 2. The wizard does not revalidate earlier steps when first validating a
 form. Thus, if a confirmation step's `clean` charges when first validated,
 and an earlier step's form fails revalidation in `render_done` (say stock
 on an item is no longer available, or a discount window has expired), the
 charge has already occurred and the `done` step will not be processed. The
 transaction is a mess at that point.

 An alternate solution would be to have earlier forms check if the charge
 has occurred and always return `valid()` in that case. I'm not sure how
 that would interact with tampering detection and the like.

 Accordingly actions which must not be duplicated are best performed in the
 `done` method. The `done` method guarantees all forms validate & the
 wizard state is deleted upon completion. The current wizard allows for
 forms which do not revalidate, but does not allow for a `done` method
 which may not complete successfully. The proposed exception handles this
 case.

 An implementation I currently use defines the `Exception` in my wizard
 subclass & then overrides `render_done` to catch the exception and step
 back into the `FormWizard` as needed. Django being open-source and Python,
 the workaround is quite functional. However I thought the problem and
 solution general enough for inclusion.

 I have attached a patch w/ tests. I can work up the docs if it would help.

 Thanks. Kent

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16748: Documentation on creating custom querysets

[Django]

#16748: Documentation on creating custom querysets
---+
 Reporter:  lee@…  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.3
 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 carbonXT):

 * cc: mike@… (added)


Comment:

 Note that the `__getattr__` definition in the above boilerplate code
 violates https://docs.djangoproject.com/en/dev/topics/db/managers
 /#implementation-concerns

 Associated discussion on #15062.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19152: Add support to create database without template_postgis with PostGIS 2

[Django]

#19152: Add support to create database without template_postgis with PostGIS 2
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  1.4
 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 tinio):

 * cc: aurelio@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19214: AdminEmailHandler is synchronous.

[Django]

#19214: AdminEmailHandler is synchronous.
---+
 Reporter:  tdhutt@…   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  AdminEmailHandler  | 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):

 * component:  Core (Other) => Core (Mail)
 * type:  Uncategorized => New feature
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 There are Django applications dedicated to sending mail asynchronously
 (https://github.com/pinax/django-mailer/ or http://pypi.python.org/pypi
 /django-celery-email).

 However I think it could be interesting to add an async flag to some
 Django mail API like `mail_admins` or `mail_managers` which would do the
 effective connection to the MTA in a thread (assuming
 `fail_silently=True`).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16572: select_related doesn't work (silent/masked TypeError) over multiple one-to-one relationships

[Django]

#16572: select_related doesn't work (silent/masked TypeError) over multiple 
one-to-
one relationships
-+-
 Reporter:  rfrankel |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related orm   |  Needs documentation:  0
  queryset   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by dvd0101):

 * cc: dvd0101 (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19213: Unicode problem loading 500 template using Python 3.3

[Django]

#19213: Unicode problem loading 500 template using Python 3.3
---+---
 Reporter:  adj7388@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Python 3   |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:  worksforme
 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):

 Note that the fix was backported to the 1.5.x branch in
 [7b6978553aa8cde493f02ddd93bbd711afbf28ae]. You can also test a checkout
 of that branch.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19213: Unicode problem loading 500 template using Python 3.3

[Django]

#19213: Unicode problem loading 500 template using Python 3.3
---+---
 Reporter:  adj7388@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Python 3   |  Version:  1.5-alpha-1
 Severity:  Normal |   Resolution:  worksforme
 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 claudep):

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


Comment:

 I think this has been fixed in [3629a159f97b03f1142acdea03bdfa91edecea8d].
 Reopen if you can reproduce it in 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19214: AdminEmailHandler is synchronous.

[Django]

#19214: AdminEmailHandler is synchronous.
---+--
 Reporter:  tdhutt@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Core (Other)   |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  AdminEmailHandler  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by tdhutt@…):

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


Comment:

 Simple fix - use the following class instead of the built in
 AdminEmailHandler in your LOGGING thing.

 {{{

 import threading

 # Class for running a function in another thread. TODO: Use this for the
 code in gcm and email2.
 class FuncThread(threading.Thread):
 def __init__(self, target, *args, **kwargs):
 self._target = target
 self._args = args
 self._kwargs = kwargs
 threading.Thread.__init__(self)

 def run(self):
 self._target(*self._args, **self._kwargs)

 import logging
 import traceback

 from django.conf import settings
 from django.core import mail
 from django.views.debug import ExceptionReporter,
 get_exception_reporter_filter


 class AdminEmailHandler(logging.Handler):
 """An exception log handler that ASYNCHRONOUSLY emails log entries to
 site admins.

 If the request is passed as the first argument to the log record,
 request data will be provided in the email report.

 The default one is blocking, which is a little silly.
 """

 def __init__(self, include_html=False):
 logging.Handler.__init__(self)
 self.include_html = include_html

 def emit(self, record):
 try:
 request = record.request
 subject = '%s (%s IP): %s' % (
 record.levelname,
 (request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS
  and 'internal' or 'EXTERNAL'),
 record.getMessage()
 )
 filter = get_exception_reporter_filter(request)
 request_repr = filter.get_request_repr(request)
 except Exception:
 subject = '%s: %s' % (
 record.levelname,
 record.getMessage()
 )
 request = None
 request_repr = "Request repr() unavailable."
 subject = self.format_subject(subject)

 if record.exc_info:
 exc_info = record.exc_info
 stack_trace =
 '\n'.join(traceback.format_exception(*record.exc_info))
 else:
 exc_info = (None, record.getMessage(), None)
 stack_trace = 'No stack trace available'

 message = "%s\n\n%s" % (stack_trace, request_repr)
 reporter = ExceptionReporter(request, is_email=True, *exc_info)
 html_message = self.include_html and reporter.get_traceback_html()
 or None
 FuncThread(mail.mail_admins, subject, message, fail_silently=True,
 html_message=html_message).start()

 def format_subject(self, subject):
 """
 Escape CR and LF characters, and limit length.
 RFC 2822's hard limit is 998 characters per line. So, minus
 "Subject: "
 the actual subject must be no longer than 989 characters.
 """
 formatted_subject = subject.replace('\n', '\\n').replace('\r',
 '\\r')
 return formatted_subject[:989]
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19214: AdminEmailHandler is synchronous.

[Django]

#19214: AdminEmailHandler is synchronous.
---+---
 Reporter:  tdhutt@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Core (Other)   |Version:  1.4
 Severity:  Normal |   Keywords:  AdminEmailHandler
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+---
 Hi set up my logging settings to email me in certain situations (e.g.
 aliens visiting my site) by doing `logger.warn("Visitor from space")` in a
 middleware class, and then setting a logger for that middleware class to
 use AdminEmailHandler. However it is useless, because AdminEmailHandler is
 synchronous! Any aliens have to wait two or three seconds for the email to
 be sent before seeing my site!

 It would be much much better if the email was asynchronous, or at least
 there was an additional AsyncAdminEmailHandler which was used by default.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #19213: Unicode problem loading 500 template using Python 3.3

[Django]

#19213: Unicode problem loading 500 template using Python 3.3
+-
 Reporter:  adj7388@…   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Python 3|Version:  1.5-alpha-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
 '''Environment:'''
 Python 3.3
 Django-1.5a1
 Windows XP

 To reproduce this error, work through the tutorial until you get to "Write
 your first view" section at:
 https://docs.djangoproject.com/en/1.5/intro/tutorial03/#write-your-first-
 view

 Introduce an intentional error, for example in 'views.py' change:
 from django.http import HttpResponse
 to
 from django.http import HttpResponseFoo

 This produces an error as expected, but while processing the error,
 another exception is generated:

 {{{
 "During handling of the above exception, another exception occurred:"
 ...  ...
   File "C:\home\alan\venvs\Django-1.5a1\lib\site-
 packages\django\views\debug.py", line 390, in get_traceback_frames
 pre_context_lineno, pre_context, context_line, post_context =
 self._get_lines_from_file(filename, lineno, 7, loader, module_name)
   File "C:\home\alan\venvs\Django-1.5a1\lib\site-
 packages\django\views\debug.py", line 361, in _get_lines_from_file
 match = re.search(br'coding[:=]\s*([-\w.]+)', line)
   File "C:\home\alan\venvs\Django-1.5a1\lib\re.py", line 161, in search
 return _compile(pattern, flags).search(string)
 TypeError: can't use a bytes pattern on a string-like object
 }}}

 Line 361 in debug.py is where things start to go wrong:

 {{{
 match = re.search(br'coding[:=]\s*([-\w.]+)', line)
 }}}

 The 'line' argument is a unicode string (type: str), but the regex is a
 byte pattern. You can get past this error by encoding line as 'ascii':

 {{{
 match = re.search(br'coding[:=]\s*([-\w.]+)', line.encode('ascii'))
 }}}

 but then you run into a similar problem a few lines later (debug.py line
 365):

 {{{
 source = [six.text_type(sline, encoding, 'replace') for sline in
 source]
 }}}

 which produces the error '''"TypeError: decoding str is not supported"'''
 because 'six.text_type' is actually the Python 'str()' function, and the
 code is telling 'str()' to decode 'sline' using the 'ascii' codec.

 Basically the 'source' list is read in from a file that produces unicode,
 but subsequent code thinks lines from the 'source' list are bytes and
 tries to apply a byte pattern regex (debug.py lines 361) or tries to
 decode the unicode (debug.py lines 365).

 I would submit a patch if I knew how to fix the underlying problem, but
 I'm not sure if the fix needs to happen in 'debug.py' or in the loader
 that gets the 'source' list.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5419: Add a model fuzz testing method to the test framework

[Django]

#5419: Add a model fuzz testing method to the test framework
---+
 Reporter:  adrian |Owner:  kkubasik
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  feature| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by d1ffuz0r):

 * cc: d1fffuz0r@… (added)


Comment:

 Interesting feature. I want try to upgrade this patch for current version
 and to make tests for 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15714: Inconsistent capitalization of name_local in django.conf.locale.LANG_INFO

[Django]

#15714: Inconsistent capitalization of name_local in 
django.conf.locale.LANG_INFO
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"5229ac20bedea017bfd29e6cb03916715c09cc7f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5229ac20bedea017bfd29e6cb03916715c09cc7f"
 [1.5.x] Fixed #15714 -- Added note about capitalization of LANG_INFO
 name_local

 Backport of 5dc4437df 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5229ac: [1.5.x] Fixed #15714 -- Added note about capitaliz...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 5229ac20bedea017bfd29e6cb03916715c09cc7f
  
https://github.com/django/django/commit/5229ac20bedea017bfd29e6cb03916715c09cc7f
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/conf/locale/__init__.py

  Log Message:
  ---
  [1.5.x] Fixed #15714 -- Added note about capitalization of LANG_INFO 
name_local

Backport of 5dc4437df from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15714: Inconsistent capitalization of name_local in django.conf.locale.LANG_INFO

[Django]

#15714: Inconsistent capitalization of name_local in 
django.conf.locale.LANG_INFO
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"5dc4437dfad8241a5830e4d2ab59635b814281d6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5dc4437dfad8241a5830e4d2ab59635b814281d6"
 Fixed #15714 -- Added note about capitalization of LANG_INFO name_local
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5dc443: Fixed #15714 -- Added note about capitalization of...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5dc4437dfad8241a5830e4d2ab59635b814281d6
  
https://github.com/django/django/commit/5dc4437dfad8241a5830e4d2ab59635b814281d6
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/conf/locale/__init__.py

  Log Message:
  ---
  Fixed #15714 -- Added note about capitalization of LANG_INFO name_local



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19036: Big base64-encoded files uploading

[Django]

#19036: Big base64-encoded files uploading
--+
 Reporter:  anthony@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  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):

 * severity:  Normal => Release blocker


Comment:

 Added blocker flag, as currently 3 of 4 base64 file uploads are doomed to
 fail.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19101: Non ascii chars in form cause Internal Server Error

[Django]

#19101: Non ascii chars in form cause Internal Server Error
-+-
 Reporter:  kristall |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  encoding | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 I've just uploaded a new patch now that #5076 has been committed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5076: Request object should try to determine encoding

[Django]

#5076: Request object should try to determine encoding
-+-
 Reporter:  dbr|Owner:  Claude
 Type:   |  Paroz 
  Cleanup/optimization   |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  unicode conversion   | Triage Stage:  Ready for
  charset POST request   |  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:"3f3076edbf8d6fb204984a1a7fddbde408d5b104"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3f3076edbf8d6fb204984a1a7fddbde408d5b104"
 [1.5.x] Fixed #5076 -- Properly decode POSTs with non-utf-8 payload
 encoding

 Thanks daniel at blogg.se for the report and Aymeric Augustin for
 his assistance on the patch.

 Backport of 6de6988f9 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3f3076: [1.5.x] Fixed #5076 -- Properly decode POSTs with ...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 3f3076edbf8d6fb204984a1a7fddbde408d5b104
  
https://github.com/django/django/commit/3f3076edbf8d6fb204984a1a7fddbde408d5b104
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/core/handlers/wsgi.py
M tests/regressiontests/requests/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #5076 -- Properly decode POSTs with non-utf-8 payload encoding

Thanks daniel at blogg.se for the report and Aymeric Augustin for
his assistance on the patch.

Backport of 6de6988f9 from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5076: Request object should try to determine encoding

[Django]

#5076: Request object should try to determine encoding
-+-
 Reporter:  dbr|Owner:  Claude
 Type:   |  Paroz 
  Cleanup/optimization   |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  unicode conversion   | Triage Stage:  Ready for
  charset POST request   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

 * owner:   => Claude Paroz 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"6de6988f9990b4b53f5a20bfc3811b3cc49291c5"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6de6988f9990b4b53f5a20bfc3811b3cc49291c5"
 Fixed #5076 -- Properly decode POSTs with non-utf-8 payload encoding

 Thanks daniel at blogg.se for the report and Aymeric Augustin for
 his assistance on the 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 6de698: Fixed #5076 -- Properly decode POSTs with non-utf-...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6de6988f9990b4b53f5a20bfc3811b3cc49291c5
  
https://github.com/django/django/commit/6de6988f9990b4b53f5a20bfc3811b3cc49291c5
  Author: Claude Paroz 
  Date:   2012-10-30 (Tue, 30 Oct 2012)

  Changed paths:
M django/core/handlers/wsgi.py
M tests/regressiontests/requests/tests.py

  Log Message:
  ---
  Fixed #5076 -- Properly decode POSTs with non-utf-8 payload encoding

Thanks daniel at blogg.se for the report and Aymeric Augustin for
his assistance on the patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.