Re: [Django] #20091: outer join regression over nullable foreign keys

[Django]

#20091: outer join regression over nullable foreign keys
-+-
 Reporter:  ikelly   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 OK, convinced.

 I will try to remember to do the patch + backport to 1.5 today.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20104: Make versionchanged directive less prone to mis-use.

[Django]

#20104: Make versionchanged directive less prone to mis-use.
---+
 Reporter:  carljm |Owner:  jcatalan
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.5
 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 jcatalan):

 Ok, here's the PR with all the changes.

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

 Hopefully, I'm not forgetting anything. Let me know what you think.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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19866: SuspiciousOperation should not be answered with HTTP 500

[Django]

#19866: SuspiciousOperation should not be answered with HTTP 500
-+
 Reporter:  tiwoc|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  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 firass):

 * cc: firass (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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
-+
 Reporter:  dstufft  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.5
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by ptone):

 Claude,

 I've given this a pretty thorough review, and it looks good.  I'm
 wondering if you forgot a {{{git clean}}} somewhere, as the tests in the
 diff were still written to the location in tests/regressiontests

 I've staged your patch, with only one small addition to a comment, just to
 clarify that the warnings may not be even captured at this point, didn't
 figure it was worth another check to sys.warnoptions, but that could be
 another way to clarify those lines (since they are so far from the
 conf/__init__ code)

 https://github.com/ptone/django/compare/18985-fix#L3R87

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6103: modeltests/model_forms/models.py could do with some rewriting

[Django]

#6103: modeltests/model_forms/models.py could do with some rewriting
-+-
 Reporter:  mtredinnick  |Owner:
 Type:   |  bharadwajdes
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bharadwajdes):

 Please let me know any specific changes to be addressed 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 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6103: modeltests/model_forms/models.py could do with some rewriting

[Django]

#6103: modeltests/model_forms/models.py could do with some rewriting
-+-
 Reporter:  mtredinnick  |Owner:
 Type:   |  bharadwajdes
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bharadwajdes):

 * owner:  nobody => bharadwajdes
 * 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20121: LogEntry.get_admin_url uses a hard-coded path format.

[Django]

#20121: LogEntry.get_admin_url uses a hard-coded path format.
--+
 Reporter:  floppya   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by charettes):

 * cc: charettes (added)
 * needs_better_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 The cleanup makes sense but [https://github.com/django/django/pull/949 the
 provided patch] makes two regression tests fails.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20117: Flatpages test failure in a project with language different to 'en'

[Django]

#20117: Flatpages test failure in a project with language different to 'en'
-+-
 Reporter:  matiasb  |Owner:  matiasb
 Type:  Bug  |   Status:  closed
Component:  contrib.flatpages|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Simon Charette ):

 In [changeset:"151938ddb5f9537c80c1a6426f2c6ce14adc92d9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="151938ddb5f9537c80c1a6426f2c6ce14adc92d9"
 Merge pull request #946 from matiasb/minor-flatpage-translation-fix

 Fixed #20117 -- Added missing translation override to fix flatpages 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20117: Flatpages test failure in a project with language different to 'en'

[Django]

#20117: Flatpages test failure in a project with language different to 'en'
-+-
 Reporter:  matiasb  |Owner:  matiasb
 Type:  Bug  |   Status:  closed
Component:  contrib.flatpages|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by matiasb ):

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


Comment:

 In [changeset:"6985f0c09bdf87509a1ca3c98f7ba45a7a9dbc0c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6985f0c09bdf87509a1ca3c98f7ba45a7a9dbc0c"
 Fixed #20117 -- Added missing translation override to fix flatpages 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 6985f0: Fixed #20117 -- Added missing translation override...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6985f0c09bdf87509a1ca3c98f7ba45a7a9dbc0c
  
https://github.com/django/django/commit/6985f0c09bdf87509a1ca3c98f7ba45a7a9dbc0c
  Author: matiasb 
  Date:   2013-03-23 (Sat, 23 Mar 2013)

  Changed paths:
M django/contrib/flatpages/tests/forms.py

  Log Message:
  ---
  Fixed #20117 -- Added missing translation override to fix flatpages test.


  Commit: 151938ddb5f9537c80c1a6426f2c6ce14adc92d9
  
https://github.com/django/django/commit/151938ddb5f9537c80c1a6426f2c6ce14adc92d9
  Author: Simon Charette 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/contrib/flatpages/tests/forms.py

  Log Message:
  ---
  Merge pull request #946 from matiasb/minor-flatpage-translation-fix

Fixed #20117 -- Added missing translation override to fix flatpages test.


Compare: https://github.com/django/django/compare/9c4882b39115...151938ddb5f9

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20091: outer join regression over nullable foreign keys

[Django]

#20091: outer join regression over nullable foreign keys
-+-
 Reporter:  ikelly   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ikelly):

 I believe the fix is important because while somefield=None would work,
 the ORM itself uses the empty string.  For example, this would produce an
 empty queryset in Oracle:

 {{{
 somechild = Child.objects.create(parent=someparent)
 Child.objects.filter(parent__somefield=somechild.parent.somefield)
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12509: Feature: Selector Inlines

[Django]

#12509: Feature: Selector Inlines
-+-
 Reporter:  zain |Owner:  zain
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  soc2009
 Severity:  Normal   |  /admin-ui
 Keywords:  design_ux|   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by charettes):

 * cc: charettes (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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17582: DoesNotExist ambiguous exception when accessed via foreign key

[Django]

#17582: DoesNotExist ambiguous exception when accessed via foreign key
-+-
 Reporter:  simon@…  |Owner:
 Type:   |  JordanPowell
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by charettes):

 * needs_better_patch:  0 => 1


Comment:

 Instead of testing for the exception message being not empty you should
 use `assertRaisesMessage` to make sure the correct message is raised.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20104: Make versionchanged directive less prone to mis-use.

[Django]

#20104: Make versionchanged directive less prone to mis-use.
---+
 Reporter:  carljm |Owner:  jcatalan
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.5
 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 jcatalan):

 Yeap, you're right, I'll change that. And I'm also going to make the
 changes in all the occurrences of versionadded/changed directive. As soon
 as I have the new patch, I'll attach it. 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17582: DoesNotExist ambiguous exception when accessed via foreign key

[Django]

#17582: DoesNotExist ambiguous exception when accessed via foreign key
-+-
 Reporter:  simon@…  |Owner:
 Type:   |  JordanPowell
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by JordanPowell):

 Just added a patch for this - let me know if anything needs changing and
 if I should issue a pull request.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20129: Storing a related queryset in attribute clears session

[Django]

#20129: Storing a related queryset in attribute clears session
--+
 Reporter:  francescortiz |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi, I don't know if I am missing something important, but I have a very
 weird behavior with this piece of code that took me some hours to find
 out:

 {{{
 class ModelA(models.Model, AbstractModel)
 ...

 def items():
 try:
 return self._items_qs_cache
 except AttributeError:
 current_minute = return datetime.now().replace(second=0,
 microsecond=0)
 self._items_qs_cache =
 self.children_set.filter(published=True, publish_date__lte=current_minute)
 return self_items_qs_cache

 parent = models.ForeignKey('self', blank=True, null=True,
 verbose_name=_('parent'), related_name='children_set')
 }}}

 Calling the items() function clears the session!

 But, if instead you replace the following line

 {{{
 self._items_qs_cache = self.children_set.filter(published=True,
 publish_date__lte=current_minute)
 }}}

 with the following equivalent one

 {{{
 self._items_qs_cache = Model.objects.filter(published=True,
 publish_date__lte=current_minute, parent=self)
 }}}

 The session does not get cleared.

 Is this a django bug or am I missing somthing.

 Thank you,

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20128: csrfmiddleware sometimes raises IOError via _load_post_and_files

[Django]

#20128: csrfmiddleware sometimes raises IOError via _load_post_and_files
--+
 Reporter:  wdoekes   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.csrf  |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Hi,

 according the recently closed #12250, process_view middleware is not
 supposed to raise exceptions.

 The documentation already states:
 """Accessing request.POST ... from process_request or process_view ...
 should normally be avoided."""
 https://docs.djangoproject.com/en/dev/topics/http/middleware/#process-view

 And here is another reason:

 Sometimes the connection is reset/lost during HTTP request (during
 post/file data upload): an IOError is generated when read()ing from the
 data stream (from _load_post_and_files()).

 Since the CsrfViewMiddleware attempts to get the csrfmiddlewaretoken from
 the POST data, the exception is propagated from there. And it's
 unhandleable, since we cannot catch exceptions from process_view().

 The attached test simulates the situation by simply raising an IOError
 when an attempt to access POST is done. The attached patch silently
 ignores the IOError and treats it as if an empty csrfmiddleware token was
 supplied.

 Regards,[[br]]
 Walter Doekes

 P.S. Reproducing the IOError (for the generic non-csrf case) in the wild
 was trivial with apache2+mod_wsgi, but harder on nginx+uwsgi. For the
 former it was a matter of killing the netcat after feeding it a large-ish
 amount of multipart/form-data.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by asksol):

 Ok, I see and agree, with the new autocommit behavior this is unlikely to
 catch users by surprise anymore, and race conditions will be more obvious
 if you're in an atomic block.  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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 "Manual transaction management" no longer exists in master. (That's why I
 closed this ticket.)

 For your use case, I recommend staying in autocommit mode (ie. avoid
 ATOMIC_REQUESTS), and not enqueuing tasks within an atomic block.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by asksol):

 right, I guess with autocommit an operation may easily consist of multiple
 transactions.   I guess the only way to do this properly is by using
 manual transaction management.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 These signals aren't enough. You also need to track savepoint rollbacks,
 otherwise you could still attempt to run a task on data that wasn't
 inserted to the database.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17582: DoesNotExist ambiguous exception when accessed via foreign key

[Django]

#17582: DoesNotExist ambiguous exception when accessed via foreign key
-+-
 Reporter:  simon@…  |Owner:
 Type:   |  JordanPowell
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by JordanPowell):

 * owner:  nobody => JordanPowell
 * 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by asksol):

 Though, with simple {transaction_start, transaction_commit,
 transaction_cancel} signals, keeping track of what to call and when would
 be Celery's problem and not Django's.  While it would be nice, it was
 never my intention that Django would implement this logic.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20127: Unify subquery generation in the ORM

[Django]

#20127: Unify subquery generation in the ORM
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

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


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

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

[Django] #20127: Unify subquery generation in the ORM

[Django]

#20127: Unify subquery generation in the ORM
--+
 Reporter:  akaariai  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There are some different ways for doing subqueries in the ORM currently.
 Query.split_exclude(), subqueries in deletion, as_nested_sql() and
 SubqueryConstraint seem to do something similar. Sometimes there are
 duplicated code paths, sometimes upper layers do something the lower
 layers will repeat later on.

 I think every instance where a subquery constrain is needed should use the
 SubqueryConstraint either directly, or through QuerySet.filter() or
 sql.Query.build_filter(). This will allow doing all the somewhat
 complicated setup in one place.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19390: NameError in models throws ambiguous message when running syncdb

[Django]

#19390: NameError in models throws ambiguous message when running syncdb
-+-
 Reporter:  dloewenherz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.5-beta-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 Imo this was fixed with 6a91b638423d.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20091: outer join regression over nullable foreign keys

[Django]

#20091: outer join regression over nullable foreign keys
-+-
 Reporter:  ikelly   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 A commit fixing this is available from
 
https://github.com/akaariai/django/commit/be3f1d35be9f2db8c4c1f8ad5e7b0f1680675cb6

 I am not sure if this should be actually fixed, wouldn't it be possible to
 just use somefield=None in this case? The fix will not work under multidb
 and I believe changes done for multidb were the reason for this
 regression.

 I will leave the commit and backpatch decision to Ian.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9c4882: Fixed Oracle specific failures in multicolumn join...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9c4882b391157f6aa3c0ade309638ffcd3bdf684
  
https://github.com/django/django/commit/9c4882b391157f6aa3c0ade309638ffcd3bdf684
  Author: Anssi Kääriäinen 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/db/models/sql/where.py

  Log Message:
  ---
  Fixed Oracle specific failures in multicolumn joins

Refs #19385



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"9c4882b391157f6aa3c0ade309638ffcd3bdf684"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9c4882b391157f6aa3c0ade309638ffcd3bdf684"
 Fixed Oracle specific failures in multicolumn joins

 Refs #19385
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19541: Reversing URLs in response middleware or streamed responses won't use per-request urlconf

[Django]

#19541: Reversing URLs in response middleware or streamed responses won't use 
per-
request urlconf
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  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 Loic Bistuer ):

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


Comment:

 In [changeset:"521765f63d724f0a1becb614530170f5d00fc6a9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="521765f63d724f0a1becb614530170f5d00fc6a9"
 Fixed #19541 -- Fixed BaseHandler to enable reversing URLs in response
 middlewares
 and streamed responses with respect to per-request urlconf.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19541: Reversing URLs in response middleware or streamed responses won't use per-request urlconf

[Django]

#19541: Reversing URLs in response middleware or streamed responses won't use 
per-
request urlconf
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  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 Jannis Leidel ):

 In [changeset:"24234555a01f3ebff2e969210024c86842896671"]:
 {{{
 #!CommitTicketReference repository=""
 revision="24234555a01f3ebff2e969210024c86842896671"
 Merge pull request #885 from loic/ticket19541

 Fixed #19541 -- Fixed BaseHandler to enable reversing URLs in response
 middlewares...
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 521765: Fixed #19541 -- Fixed BaseHandler to enable revers...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 521765f63d724f0a1becb614530170f5d00fc6a9
  
https://github.com/django/django/commit/521765f63d724f0a1becb614530170f5d00fc6a9
  Author: Loic Bistuer 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/core/handlers/base.py
M django/test/testcases.py
M tests/urlpatterns_reverse/middleware.py
M tests/urlpatterns_reverse/tests.py

  Log Message:
  ---
  Fixed #19541 -- Fixed BaseHandler to enable reversing URLs in response 
middlewares
and streamed responses with respect to per-request urlconf.


  Commit: 24234555a01f3ebff2e969210024c86842896671
  
https://github.com/django/django/commit/24234555a01f3ebff2e969210024c86842896671
  Author: Jannis Leidel 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/core/handlers/base.py
M django/test/testcases.py
M tests/urlpatterns_reverse/middleware.py
M tests/urlpatterns_reverse/tests.py

  Log Message:
  ---
  Merge pull request #885 from loic/ticket19541

Fixed #19541 -- Fixed BaseHandler to enable reversing URLs in response 
middlewares...


Compare: https://github.com/django/django/compare/0e0eb8a9553b...24234555a01f

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20122: Pluralize filter sometimes returns singular form instead of an empty string for invalid inputs

[Django]

#20122: Pluralize filter sometimes returns singular form instead of an empty 
string
for invalid inputs
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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
--+
Changes (by claudep):

 * 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"0e0eb8a9553bb89347ceb159537ccc417cb5e7f5"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0e0eb8a9553bb89347ceb159537ccc417cb5e7f5"
 Fixed field.rel.field_name handling

 This is a regression fix to multicolumn joins. Refs #19385.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 0e0eb8: Fixed field.rel.field_name handling

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0e0eb8a9553bb89347ceb159537ccc417cb5e7f5
  
https://github.com/django/django/commit/0e0eb8a9553bb89347ceb159537ccc417cb5e7f5
  Author: Anssi Kääriäinen 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/db/models/fields/related.py

  Log Message:
  ---
  Fixed field.rel.field_name handling

This is a regression fix to multicolumn joins. Refs #19385.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20120: If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a console warning

[Django]

#20120: If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a 
console
warning
---+--
 Reporter:  ty@…   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by tghw):

 That's certainly possible, but at least people would be aware of it. I've
 been using Django since the pre-1.0 days, and while I know I should, I
 also know that I'm like a lot of developers in that I don't read the
 release notes for every single new version.

 I'd ask you to reconsider. Documentation is rarely a good solution for
 something that will completely break a site like ALLOWED_HOSTS will.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20120: If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a console warning

[Django]

#20120: If DEBUG mode is True and ALLOWED_HOSTS is empty you should get a 
console
warning
---+--
 Reporter:  ty@…   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 And then you add localhost to `ALLOWED_HOSTS` to silence the warning, and
 we are back to the original situation.

 There is now a deployment checklist that is a good reference for building
 the deployment-ready settings.
 https://docs.djangoproject.com/en/dev/howto/deployment/checklist/

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20104: Make versionchanged directive less prone to mis-use.

[Django]

#20104: Make versionchanged directive less prone to mis-use.
---+
 Reporter:  carljm |Owner:  jcatalan
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.5
 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 timo):

 Instead of hardcoding "versionchanged" in the exception that's raised in
 djangodocs.py, I suggest using string interpolation and self.name so that
 the exception properly reflects either versionchanged or versionadded.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20114: Failures in tests in django.contrib.auth when using custom LOGIN_URL/LOGOUT_URL

[Django]

#20114: Failures in tests in django.contrib.auth when using custom
LOGIN_URL/LOGOUT_URL
--+
 Reporter:  jriley@…  |Owner:  matiasb
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by matiasb):

 * has_patch:  0 => 1


Comment:

 Proposed pull request: https://github.com/django/django/pull/952
 Tests passing with SQLite.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19396: Allow customized ModelState classes

[Django]

#19396: Allow customized ModelState classes
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by apollo13):

 * stage:  Design decision needed => Accepted


Comment:

 I think it would be great to have.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16227: Include traceback in a comment when hitting an exception in debug mode

[Django]

#16227: Include traceback in a comment when hitting an exception in debug mode
-+-
 Reporter:  Odd_Bloke|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  1
-+-
Changes (by apollo13):

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


Comment:

 I think we don't need a feature like this, with the LOGGING framework you
 can easily add a console handler to 'django.request' and get a trace in
 the runserver console.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14057: Expose an interface for custom-escaping template content

[Django]

#14057: Expose an interface for custom-escaping template content
-+-
 Reporter:  steveire |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 I agree with Aymeric. I also think that the escaping system should stay as
 easy as possible, especially since we want it to be secure.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19117: Database and memcached connections break after fork.

[Django]

#19117: Database and memcached connections break after fork.
-+-
 Reporter:  sebastian_noack  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by apollo13):

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


Comment:

 I agree with Aymeric.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20091: outer join regression over nullable foreign keys

[Django]

#20091: outer join regression over nullable foreign keys
-+-
 Reporter:  ikelly   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 This seems to be regression from 1.1 to 1.2, in 1.1 add_filter() contains
 a value = "" and connection interprets emptry strings as nulls check, in
 1.2 that is gone.

 As such I don't see this as a regression and thus this isn't prime
 candidate for backpatch. Of course, the patch is going to be pretty
 simple, and if a core committer is willing to backpatch this to 1.5 I am
 not going to complain...

 I will try to commit a patch to master soon, it will not apply directly to
 1.5 due to changes between master and 1.5.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19897: Improve static files documentation

[Django]

#19897: Improve static files documentation
--+
 Reporter:  wimfeijen |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  staticfiles   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by jezdez):

 5. Ah, makes sense.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19897: Improve static files documentation

[Django]

#19897: Improve static files documentation
--+
 Reporter:  wimfeijen |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  staticfiles   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by jezdez):

 Thanks for the review, timo! I'm just going to reply to your questions :)

 1. django-staticfiles hasn't been updated for a while now and should be
 removed from our docs. contrib-staticfiles is the defacto staticfiles.

 2. Hm, the context processor should definitely be documented, although the
 ref section should be enough. Everybody should use the template tag.

 3. The note should maybe move to the deprecation timeline and linked from
 the staticfiles docs, many of the current beginners don't remember
 MEDIA_ROOT as the location of non-upload files anymore, so I think this
 section is purely historical.

 4. Oh, that's odd, hm, this should definitely be mentioned in a reference
 doc style. It's not important for the tutorial though, IMO.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
-+
 Reporter:  dstufft  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.5
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * version:  master => 1.5


Comment:

 Sorry, didn't mean to reset version.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
-+
 Reporter:  dstufft  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by claudep):

 * version:  1.5 => master


Comment:

 Here's my recent findings about this issue:

 Warnings are redirected to the logging system, which is configured by
 default to use the `'console'` handler. By default, that handler is
 filtering out events when DEBUG is False. That is wanted for deployed
 Django apps, except for tests. That was the reason for commit
 [cfa70d0c94a43d9].
 Unfortunately, all warnings emitted from the time they are redirected to
 the logging system until `DjangoTestSuiteRunner.run_tests` force to
 reenable warnings display are lost (module-level warnings), because DEBUG
 is initially False.

 So one solution is to reenable the non-filtering `StreamHandler` for
 'py.warnings' sooner in the process, in `setup()` of `runtests.py` (before
 `get_apps()` which triggers the module warnings).

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5e2bb1: [1.5.X] Fixed signature of HttpResponse.set_signed...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 5e2bb1223c4e622113cef0edb6d7df53fab0367c
  
https://github.com/django/django/commit/5e2bb1223c4e622113cef0edb6d7df53fab0367c
  Author: Yohan Boniface 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/ref/request-response.txt

  Log Message:
  ---
  [1.5.X] Fixed signature of HttpResponse.set_signed_cookie in docs.

Backport of c5b2414a52 from master



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] c5b241: Doc: "value" is arg not kwarg in HttpResponse.set_...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c5b2414a52c0959acbcf107a60bf129539e2415e
  
https://github.com/django/django/commit/c5b2414a52c0959acbcf107a60bf129539e2415e
  Author: Yohan Boniface 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/ref/request-response.txt

  Log Message:
  ---
  Doc: "value" is arg not kwarg in HttpResponse.set_signed_cookie


  Commit: 014638a1311dfc64e6f6eed28f12eeb227926150
  
https://github.com/django/django/commit/014638a1311dfc64e6f6eed28f12eeb227926150
  Author: Tim Graham 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/ref/request-response.txt

  Log Message:
  ---
  Merge pull request #951 from yohanboniface/set_signed_cookie

Fixed signature of HttpResponse.set_signed_cookie in docs.


Compare: https://github.com/django/django/compare/6073091b7745...014638a1311d

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20124: Warnings when building the docs

[Django]

#20124: Warnings when building the docs
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   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 Tim Graham ):

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


Comment:

 In [changeset:"6073091b77458da34c74c313b1395b4214874db1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6073091b77458da34c74c313b1395b4214874db1"
 Fixed #20124 - Fixed doc warnings.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 607309: Fixed #20124 - Fixed doc warnings.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6073091b77458da34c74c313b1395b4214874db1
  
https://github.com/django/django/commit/6073091b77458da34c74c313b1395b4214874db1
  Author: Tim Graham 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/ref/contrib/messages.txt
M docs/releases/1.6.txt

  Log Message:
  ---
  Fixed #20124 - Fixed doc warnings.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19866: SuspiciousOperation should not be answered with HTTP 500

[Django]

#19866: SuspiciousOperation should not be answered with HTTP 500
-+
 Reporter:  tiwoc|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  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 jshuping):

 * cc: jshuping (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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] f02c6c: Goodbye, Malcolm.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f02c6c27600c6e78b3f4bb3447cfc025a1f27a90
  
https://github.com/django/django/commit/f02c6c27600c6e78b3f4bb3447cfc025a1f27a90
  Author: Aymeric Augustin 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/internals/committers.txt

  Log Message:
  ---
  Goodbye, Malcolm.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
-+
 Reporter:  dstufft  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.5
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by jacob):

 * version:  master => 1.5


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20099: Allow filtering 404 reports by user agent

[Django]

#20099: Allow filtering 404 reports by user agent
---+
 Reporter:  coolRR |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by coolRR):

 New patch with docs addition attached.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9572a3: Python 2.6 compatibility for #19385

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9572a3992b3f92ef6c77f51c44497e18d168a30c
  
https://github.com/django/django/commit/9572a3992b3f92ef6c77f51c44497e18d168a30c
  Author: Anssi Kääriäinen 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/db/models/fields/related.py

  Log Message:
  ---
  Python 2.6 compatibility for #19385



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Anssi Kääriäinen ):

 In [changeset:"97774429aeb54df4c09895c07cd1b09e70201f7d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="97774429aeb54df4c09895c07cd1b09e70201f7d"
 Fixed #19385 again, now with real code changes

 The commit of 266de5f9ae9e9f2fbfaec3b7e4b5fb9941967801 included only
 tests, this time also code changes included...
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 977744: Fixed #19385 again, now with real code changes

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 97774429aeb54df4c09895c07cd1b09e70201f7d
  
https://github.com/django/django/commit/97774429aeb54df4c09895c07cd1b09e70201f7d
  Author: Anssi Kääriäinen 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/contrib/contenttypes/generic.py
M django/core/management/validation.py
M django/db/backends/mysql/compiler.py
M django/db/models/__init__.py
M django/db/models/base.py
M django/db/models/deletion.py
M django/db/models/fields/__init__.py
M django/db/models/fields/related.py
M django/db/models/options.py
M django/db/models/query.py
M django/db/models/related.py
M django/db/models/sql/compiler.py
M django/db/models/sql/constants.py
M django/db/models/sql/expressions.py
M django/db/models/sql/query.py
M django/db/models/sql/where.py
M django/forms/models.py

  Log Message:
  ---
  Fixed #19385 again, now with real code changes

The commit of 266de5f9ae9e9f2fbfaec3b7e4b5fb9941967801 included only
tests, this time also code changes included...



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19385: Add support for multiple-column join

[Django]

#19385: Add support for multiple-column join
-+-
 Reporter:  cseibert |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  join |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 This got fixed in [266de5f9ae9e9f2fbfaec3b7e4b5fb9941967801].

 I did still some improvements to how GenericRelation works, it is now pure
 virtual field and it isn't m2m at all. Things seem to work nicely.

 I guarantee that the commit will introduce regressions, and that there are
 things that do not work as wanted with multicolumn joins and/or when using
 plain ForeignObject. Still, I (obviously) think that commit was the right
 thing to do, as writing a perfect patch would have meant refactoring
 model._meta field representations, and even bigger refactor to
 fields/related.py. 700 lines of changed ORM code in one patch is enough...

 A big thank you to Jeremy Tillman for 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 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 266de5: Fixed 19385 -- Added ORM support for multicolumn j...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 266de5f9ae9e9f2fbfaec3b7e4b5fb9941967801
  
https://github.com/django/django/commit/266de5f9ae9e9f2fbfaec3b7e4b5fb9941967801
  Author: Anssi Kääriäinen 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
A tests/foreign_object/__init__.py
A tests/foreign_object/models.py
A tests/foreign_object/tests.py

  Log Message:
  ---
  Fixed 19385 -- Added ORM support for multicolumn joins

This patch iproved two major parts in Django. First, the fields.related
was refactored. The main addition there was ForeignObject. Second, the
ORM now handles multicolumn joins in most cases, though there are still
cases that do not work correcly (split_exclude() for example).

In addition there were extesive changes to how GenericRelation works.
Before it was a fake m2m field, now it is a pure virtual fields and is
based on ForeignObject.

There is still much room for improvement. The related fields code is
still somewhat confusing, and how fields are represented in model._meta
should also be revisited.

This patch was written mostly by Jeremy Tillman with some final polish
by the committer.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18714: Add an option to compilemessages to compile fuzzy translations

[Django]

#18714: Add an option to compilemessages to compile fuzzy translations
-+-
 Reporter:  rasca|Owner:  bak1an
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  compilemessages  |  Needs documentation:  0
  fuzzy msgfmt   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bak1an):

 * owner:  nobody => bak1an
 * cc: antonbaklanov@… (added)
 * version:  1.4 => master
 * 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20114: Failures in tests in django.contrib.auth when using custom LOGIN_URL/LOGOUT_URL

[Django]

#20114: Failures in tests in django.contrib.auth when using custom
LOGIN_URL/LOGOUT_URL
--+
 Reporter:  jriley@…  |Owner:  matiasb
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  tests | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by matiasb):

 * owner:  nobody => matiasb
 * 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16027: Include app_label in ContentType.__unicode__

[Django]

#16027: Include app_label in ContentType.__unicode__
-+-
 Reporter:  jakub|Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:   |   Resolution:
  contrib.contenttypes   | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by jakub):

 @ptone:

 When there are multiple models with the same class name (or
 `Meta.verbose_name`). eg.:

 1. `app1.models.Article`
 2. `app2.models.Article`

 Then `ContentType` selects in the admin look like this:


 {{{
 
 Article
 Article
 
 }}}

 The problem is that you cannot distinguish those two content types in the
 select without inspecting the HTML code and use the PKs as a cue.

 The patch I submitted changes the `ContentType.__unicode__()` so that it
 returns `" (.)"` instead of just the
 verbose name, eliminating the problem:


 {{{
 
 Article (app1.Article)
 Article (app2.Article)
 
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12250: process_view middleware prevents process_exception handling

[Django]

#12250: process_view middleware prevents process_exception handling
-+-
 Reporter:  manfre   |Owner:  manfre
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  middleware   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 Yes please. Sorry, I missed that in the comments.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12250: process_view middleware prevents process_exception handling

[Django]

#12250: process_view middleware prevents process_exception handling
-+-
 Reporter:  manfre   |Owner:  manfre
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  middleware   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by wdoekes):

 Should I create a new ticket for the unhandled exception in the csrf
 middleware then? :)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12250: process_view middleware prevents process_exception handling

[Django]

#12250: process_view middleware prevents process_exception handling
-+-
 Reporter:  manfre   |Owner:  manfre
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  middleware   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Overall, the current design of the request handler assumes that middleware
 methods won't raise exceptions. They must deal with their own exceptions.
 Exceptions raised by middleware will end up in handle_uncaught_exception
 and produce a 500.

 This may have some drawbacks, but at least it's consistent. Aborting on
 the first exception also avoids the problem of deciding which middleware
 should or shouldn't run after the first exception.

 I could consider a different behavior, but that would require a global
 proposal for consistent exception handling in middleware. It seems quite
 tricky to design something that is useful, consistent, and simple.

 I'm going to close this ticket because it's a piecewise approach of the
 problem that introduces some inconsistency.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] bc35b9: Fixed test failures introduced in e16c48e001.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: bc35b95274e0c98c09cf5db5407c0d43f2a1d362
  
https://github.com/django/django/commit/bc35b95274e0c98c09cf5db5407c0d43f2a1d362
  Author: Aymeric Augustin 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M tests/admin_views/models.py
M tests/one_to_one_regress/models.py

  Log Message:
  ---
  Fixed test failures introduced in e16c48e001.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17489: Errors low in the stack provide unhelpful text.

[Django]

#17489: Errors low in the stack provide unhelpful text.
-+-
 Reporter:  issackelly   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:
 Severity:  Normal   |  1.4-alpha-1
 Keywords:   |   Resolution:  wontfix
Has patch:  0| Triage Stage:  Design
  Needs tests:  0|  decision needed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


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

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

Re: [Django] #8713: Django core depends on django.contrib

[Django]

#8713: Django core depends on django.contrib
-+-
 Reporter:  Piotr Lewandowski|Owner:  nobody
   |   Status:  new
 Type:  New feature  |  Version:  master
Component:  Core (Other) |   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 filed #20126 for action 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18985: DeprecationWarning no longer loud by default in Python 2.7+

[Django]

#18985: DeprecationWarning no longer loud by default in Python 2.7+
-+
 Reporter:  dstufft  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

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


Comment:

 In some circumstances, this change silences deprecation warnings even
 under -Wd — I hope you appreciate the irony ;)

 I'm not sure how this happens exactly, but it affects warnings emitted at
 compile time (ie. at the module level).

 This emits a pending deprecation warning:
 {{{
 tests % PYTHONPATH=.. python2.6 -Wd runtests.py --settings=test_sqlite
 comments
 }}}

 This doesn't:
 {{{
 tests % PYTHONPATH=.. python2.7 -Wd runtests.py --settings=test_sqlite
 comments
 }}}

 Reverting this change fixes the second case.

 

 Currently, the 1.5 branch contains several module-level deprecation
 warnings:

 {{{
 django % grep -r -A2 '^warnings\.warn' django
 django/conf/urls/defaults.py:warnings.warn("django.conf.urls.defaults is
 deprecated; use django.conf.urls instead",
 django/conf/urls/defaults.py-  DeprecationWarning)
 django/conf/urls/defaults.py-
 --
 django/contrib/databrowse/__init__.py:warnings.warn("The Databrowse
 contrib app is deprecated", DeprecationWarning)
 --
 
django/contrib/localflavor/__init__.py:warnings.warn("django.contrib.localflavor
 is deprecated. Use the separate django-localflavor-* packages instead.",
 DeprecationWarning)
 --
 django/contrib/localflavor/id/id_choices.py:warnings.warn(
 django/contrib/localflavor/id/id_choices.py-'There have been recent
 changes to the ID localflavor. See the release notes for details',
 django/contrib/localflavor/id/id_choices.py-RuntimeWarning
 --
 django/contrib/localflavor/uk/forms.py:warnings.warn(
 django/contrib/localflavor/uk/forms.py-'The "UK" prefix for United
 Kingdom has been deprecated in favour of the '
 django/contrib/localflavor/uk/forms.py-'GB code. Please use the new
 GB-prefixed names.', DeprecationWarning)
 --
 django/contrib/localflavor/uk/uk_regions.py:warnings.warn(
 django/contrib/localflavor/uk/uk_regions.py-'The "UK" prefix for
 United Kingdom has been deprecated in favour of the '
 django/contrib/localflavor/uk/uk_regions.py-'GB code. Please use the
 new GB-prefixed names.', DeprecationWarning)
 --
 django/utils/copycompat.py:warnings.warn("django.utils.copycompat is
 deprecated; use the native copy module instead",
 django/utils/copycompat.py-  DeprecationWarning)
 django/utils/copycompat.py-
 --
 django/utils/hashcompat.py:warnings.warn("django.utils.hashcompat is
 deprecated; use hashlib instead",
 django/utils/hashcompat.py-  DeprecationWarning)
 django/utils/hashcompat.py-
 --
 django/utils/simplejson.py:warnings.warn("django.utils.simplejson is
 deprecated; use json instead.",
 django/utils/simplejson.py-  PendingDeprecationWarning)
 django/utils/simplejson.py-
 }}}

 These warnings are currently silent in 1.5, even under -Wd, and some of
 these features have already been removed in 1.6!

 That's also why #20065 wasn't detected earlier — Jacob and I spent a bit
 of time and didn't think of running tests under 2.6.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8968: No way to utilize `next` parameter to redirect after comment deletion

[Django]

#8968: No way to utilize `next` parameter to redirect after comment deletion
--+
 Reporter:  Dzhus |Owner:  kkubasik
 Type:  New feature   |   Status:  closed
Component:  contrib.comments  |  Version:  1.0
 Severity:  Normal|   Resolution:  wontfix
 Keywords:  comments  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

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


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

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

[Django] #20126: Move XViewMiddleware to django.contrib.admindocs.middleware

[Django]

#20126: Move XViewMiddleware to django.contrib.admindocs.middleware
+
   Reporter:  aaugustin |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admindocs |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 This middleware is written for by admindocs, and I don't think it has any
 other uses.

 This change would:
 - remove a dependency of core on contrib -- see the first bullet point of
 https://code.djangoproject.com/ticket/8713#comment:13
 - make the middleware reference docs more focused

 This requires a trivial deprecation path.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] e12aad: Added changes missing from previous commit.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e12aad2d57f76f8acbc369feb257cea342cc30c8
  
https://github.com/django/django/commit/e12aad2d57f76f8acbc369feb257cea342cc30c8
  Author: Aymeric Augustin 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/releases/1.6.txt

  Log Message:
  ---
  Added changes missing from previous commit.

Sorry.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10206: admin/auth/user/* templates should be in django.contrib.auth app

[Django]

#10206: admin/auth/user/* templates should be in django.contrib.auth app
---+---
 Reporter:  izibi  |Owner:  SmileyChris
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.0
 Severity:  Normal |   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):

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


Comment:

 admin requires auth; "the auth app is not installed" isn't really
 possible.

 The other way round is possible: you can use auth without the admin. In
 that case, the current templates wouldn't work, because they extend
 admin/base.html which wouldn't be accessible.

 Therefore keeping these templates in the admin app is correct.

 One could argue that "using the admin with an API-compatible re-
 implementation of auth that requires different templates" is possible, but
 that's much less common than "using auth but not the admin", all the more
 since Django now supports custom user 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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20125: get_language_from_request() - inconsistent use of fallback language

[Django]

#20125: get_language_from_request() - inconsistent use of fallback language
--+
 Reporter:  lwarx |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Internationalization  |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 To set language code
 django.utils.translation.trans_real.get_language_from_request() consults
 four places in the following order:

 1. url - get_language_from_path()
 2. session - request.session.get('django_language', None)
 3. cookie - request.COOKIES.get(settings.LANGUAGE_COOKIE_NAME)
 4. accept-language header - request.META.get('HTTP_ACCEPT_LANGUAGE', '')

 Its docsting says:

 Analyzes the request to find what language the user wants the system
 to
 show. Only languages listed in settings.LANGUAGES are taken into
 account.
 **If the user requests a sublanguage where we have a main language, we
 send
 out the main language.**

 (1) and (2) do not use get_supported_language_variant() function (which
 uses available main language when there is no sublanguage), making it
 impossible to always have full locale in url or session. Consider this
 use-case:

 I want to build a site which will be available in several countries, and
 some of them have more than one official language. To do that, I allocate
 several url prefixes (locales) to always contain both language and
 country:

 * /fr-ca/
 * /en-ca/
 * /en-us/
 * /en-gb/

 Using this scheme there is no need to have separate country selector in
 the url, and I can have only generic translations like 'en' and 'fr' with
 the possibility to add specific ones like 'en-gb'.

 Is it worth to unify fallback language handling to allow full locale in
 url and session? There is also two recently closed related tickets: #19811
 and #19763

 Also this logic is not very easy to override - I can subclass
 LocaleMiddleware.process_request(), but get_language_from_request() is
 still monolithic. I think it is better to move accept-language
 normalization to separate function.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20099: Allow filtering 404 reports by user agent

[Django]

#20099: Allow filtering 404 reports by user agent
---+
 Reporter:  coolRR |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 #10214 was closed as a duplicate. The patch for this ticket should add a
 note in the docs, explaining that subclassing the middleware is the
 recommended way to alter its behavior.

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

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

Re: [Django] #10214: Add 'internal' option to SEND_BROKEN_LINK_EMAILS

[Django]

#10214: Add 'internal' option to SEND_BROKEN_LINK_EMAILS
--+-
 Reporter:  mail@…|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  1.0
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by aaugustin):

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


Comment:

 Since my last comment, I split out this feature in its own middleware, and
 I deprecated SEND_BROKEN_LINK_EMAILS.

 #20099 will make it easier to customize the behavior to your liking, by
 subclassing this middleware.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8968: No way to utilize `next` parameter to redirect after comment deletion

[Django]

#8968: No way to utilize `next` parameter to redirect after comment deletion
--+
 Reporter:  Dzhus |Owner:  kkubasik
 Type:  New feature   |   Status:  new
Component:  contrib.comments  |  Version:  1.0
 Severity:  Normal|   Resolution:
 Keywords:  comments  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 `django.contrib.comments` has been deprecated and is no longer supported,
 so I'm closing this ticket. We're encouraging users to transition to a
 custom solution, or to a hosted solution like Disqus.

 The code itself has moved to https://github.com/django/django-contrib-
 comments; if you want to keep using it, you could move this bug over
 there.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8927: Make Request proxy the WSGI environ

[Django]

#8927: Make Request proxy the WSGI environ
---+
 Reporter:  simon  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   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):

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


Comment:

 Django's WSGI support has improved a lot since this ticket was filed, and
 as explained by Carl in comments 15 and 18, I would be hard to retrofit
 this feature. It's a fairly large backwards incompatibility for debatable
 benefits.

 If you feel strongly about this, please make a precise proposal on the
 django-developers mailing list, addressing backwards-compatibility
 concerns.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18731: "makemessages" management command should handle import aliases

[Django]

#18731: "makemessages" management command should handle import aliases
-+-
 Reporter:  diabeteman   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  makemessages i18n|  Needs documentation:  1
  gettext|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by diabeteman):

 Hello,

 I wrote docs and tests in a new patch against master. Tell me if I need to
 change something  :)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20124: Warnings when building the docs

[Django]

#20124: Warnings when building the docs
+
   Reporter:  aaugustin |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Nothing too bad, but we should fix them.

 {{{
 checking consistency...
 /Users/myk/Documents/dev/django/docs/obsolete/index.txt:: WARNING:
 document isn't included in any toctree
 /Users/myk/Documents/dev/django/docs/releases/1.6.txt:135: WARNING:
 py:class reference target not found:
 django.contrib.messages.views.SuccessMessageMixin
 /Users/myk/Documents/dev/django/docs/releases/1.6.txt:135: WARNING:
 py:class reference target not found: django.view.generic.edit.FormView
 /Users/myk/Documents/dev/django/docs/releases/1.6.txt:172: WARNING:
 py:func reference target not found: django.forms.fields.Field.__init__
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15124: BooleanField should not use False as default (unless provided)

[Django]

#15124: BooleanField should not use False as default (unless provided)
-+-
 Reporter:  andrewbadr   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-alpha-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 Aymeric Augustin ):

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


Comment:

 In [changeset:"e16c48e001ccd06830bb0bfd1d20e22ec30fce59"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e16c48e001ccd06830bb0bfd1d20e22ec30fce59"
 Fixed #15124 -- Changed the default for BooleanField.

 Thanks to the many contributors who updated and improved the patch over
 the life of this 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 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] e16c48: Fixed #15124 -- Changed the default for BooleanFie...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e16c48e001ccd06830bb0bfd1d20e22ec30fce59
  
https://github.com/django/django/commit/e16c48e001ccd06830bb0bfd1d20e22ec30fce59
  Author: Aymeric Augustin 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/contrib/flatpages/models.py
M django/db/models/fields/__init__.py
M docs/ref/models/fields.txt
M docs/releases/1.6.txt
M tests/model_fields/tests.py
M tests/model_inheritance_regress/tests.py

  Log Message:
  ---
  Fixed #15124 -- Changed the default for BooleanField.

Thanks to the many contributors who updated and improved the patch over
the life of this ticket.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20123: Non-existing email error should not be displayed on password_reset

[Django]

#20123: Non-existing email error should not be displayed on password_reset
-+-
 Reporter:  carlos.olmedo.e@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.5
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  security, message,   | Triage Stage:
  email, password_reset  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Duplicate of #19758 which was fixed a month ago.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ae417d: Added release notes for 4b31a6a9.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ae417dd4d569669e8e1d8f15e643c6ba0820aafe
  
https://github.com/django/django/commit/ae417dd4d569669e8e1d8f15e643c6ba0820aafe
  Author: Aymeric Augustin 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M docs/releases/1.6.txt
M docs/topics/db/transactions.txt

  Log Message:
  ---
  Added release notes for 4b31a6a9.

Thanks Florian for reporting this omission.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20123: Non-existing email error should not be displayed on password_reset

[Django]

#20123: Non-existing email error should not be displayed on password_reset
-+-
 Reporter:  carlos.olmedo.e@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  security, message,   | Triage Stage:
  email, password_reset  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 The documentation says "If the email address provided does not exist in
 the system, this view won’t send an email, but the user won’t receive any
 error message either. This prevents information leaking to potential
 attackers. If you want to provide an error message in this case, you can
 subclass PasswordResetForm and use the password_reset_form argument."

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20123: Non-existing email error should not be displayed on password_reset

[Django]

#20123: Non-existing email error should not be displayed on password_reset
-+-
 Reporter:   |  Owner:  nobody
  carlos.olmedo.e@…  | Status:  new
 Type:  Bug  |Version:  1.5
Component:   |   Keywords:  security, message, email,
  contrib.auth   |  password_reset
 Severity:  Normal   |  Has patch:  0
 Triage Stage:   |  UI/UX:  0
  Unreviewed |
Easy pickings:  0|
-+-
 Due to security reasons the error message "That email address doesn't have
 an associated user account. Are you sure you've registered?" should not be
 displayed on password_reset view as stated in
 https://docs.djangoproject.com/en/dev/topics/auth/default/.

 Template code: http://dpaste.com/hold/1033271/
 Urls.py: http://dpaste.com/hold/1033272/

 I'm using django 1.5 and python 3.2.3

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16216: Replace all occurences of img src attributes with css backgrounds

[Django]

#16216: Replace all occurences of img src attributes with css backgrounds
--+
 Reporter:  bheesink  |Owner:  zerok
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  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:  1
--+

Comment (by zerok):

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

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20116: ValidationError in form wizard with formsets

[Django]

#20116: ValidationError in form wizard with formsets
---+--
 Reporter:  foonicorn  |Owner:  foonicorn
 Type:  Bug|   Status:  assigned
Component:  contrib.formtools  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  formset, wizard| Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by foonicorn):

 Updated patch with tests for correct step after each POST request in
 `FormsetWizardTests`

 
https://github.com/foonicorn/django/commit/d906b549065d231a8849ce0c94c7458e18bde08f

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8490: path_info equals script_name on lighttpd using fastcgi under a subdirectory when accessed without a trailing '/'

[Django]

#8490: path_info equals script_name on lighttpd using fastcgi under a 
subdirectory
when accessed without a trailing '/'
-+-
   Reporter:  mtrichardson   |Owner:  nobody
   Type: |   Status:  closed
  Component:  Core (Other)   |  Version:  master
   Severity: |   Resolution:  fixed
   Keywords:  path_info, | Triage Stage:  Accepted
  script_name, lighttpd, fastcgi |  Needs documentation:  0
  Has patch:  1  |  Patch needs improvement:  0
Needs tests:  0  |
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"f5dbb566ee07bf3328015c70574b832052b4ebb7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5dbb566ee07bf3328015c70574b832052b4ebb7"
 Fixed #17550 -- Removed a workaround for a bug in flup 1.0.1.

 This reverts commit 948a833eb7fd9be0bc2d585c92a407f036ef42b2.

 flup appears to be dead, and this fix breaks legitimate uses of Django.

 Refs #8490.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17550: WSGI request to /subdir/subdir returns the index page

[Django]

#17550: WSGI request to /subdir/subdir returns the index page
-+---
 Reporter:  vdboor   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.4-alpha-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 Aymeric Augustin ):

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


Comment:

 In [changeset:"f5dbb566ee07bf3328015c70574b832052b4ebb7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5dbb566ee07bf3328015c70574b832052b4ebb7"
 Fixed #17550 -- Removed a workaround for a bug in flup 1.0.1.

 This reverts commit 948a833eb7fd9be0bc2d585c92a407f036ef42b2.

 flup appears to be dead, and this fix breaks legitimate uses of Django.

 Refs #8490.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] f5dbb5: Fixed #17550 -- Removed a workaround for a bug in ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f5dbb566ee07bf3328015c70574b832052b4ebb7
  
https://github.com/django/django/commit/f5dbb566ee07bf3328015c70574b832052b4ebb7
  Author: Aymeric Augustin 
  Date:   2013-03-24 (Sun, 24 Mar 2013)

  Changed paths:
M django/core/handlers/wsgi.py

  Log Message:
  ---
  Fixed #17550 -- Removed a workaround for a bug in flup 1.0.1.

This reverts commit 948a833eb7fd9be0bc2d585c92a407f036ef42b2.

flup appears to be dead, and this fix breaks legitimate uses of Django.

Refs #8490.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20116: ValidationError in form wizard with formsets

[Django]

#20116: ValidationError in form wizard with formsets
---+--
 Reporter:  foonicorn  |Owner:  foonicorn
 Type:  Bug|   Status:  assigned
Component:  contrib.formtools  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords:  formset, wizard| Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by foonicorn):

 * status:  new => assigned
 * owner:  nobody => foonicorn
 * has_patch:  0 => 1


Comment:

 I've created a patch that renders the unbound first step if a POST request
 is sent to a not initialized wizard (storage has no current step). This is
 the wizard's behavior with normal forms.

 Because of this I had to update some tests which did POST requests without
 preceding GET.

 The named wizard is not affected by the issue because the step is
 addressed in the URL and the data is always directed to the correct form.
 However in one case step_url had to be assigned to storage.current_step to
 make the behavior consistent.

 
https://github.com/foonicorn/django/commit/e95124e11ddfcfec356ade1026f6ddfa58bbbd89

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20122: Pluralize filter sometimes returns singular form instead of an empty string for invalid inputs

[Django]

#20122: Pluralize filter sometimes returns singular form instead of an empty 
string
for invalid inputs
+
   Reporter:  aaugustin |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Template system   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Filters are documented to return either their input unchanged, or the
 empty string, whatever makes most sense, when they're used incorrectly.
 The `pluralize` filter returns the empty string in such cases, for
 instance when it receives more than two forms (singular, plural).

 However, it returns the singular form instead of the empty string when
 it's passed an object that isn't a number, a string or a list.

 Failing test case:

 {{{
 --- a/tests/defaultfilters/tests.py
 +++ b/tests/defaultfilters/tests.py
 @@ -622,6 +622,9 @@ class DefaultFiltersTests(TestCase):
  self.assertEqual(pluralize(2,'y,ies'), 'ies')
  self.assertEqual(pluralize(0,'y,ies,error'), '')

 +def test_pluralize_error(self):
 +self.assertEqual(pluralize(object, 'y,ies'), '')
 +
  def test_phone2numeric(self):
  self.assertEqual(phone2numeric_filter('0800 flowers'), '0800
 3569377')

 }}}

 I understand that the implementation is crafted to avoid `isinstance`
 checks, but in this case we really want different logic depending on the
 type of the input. I think the filter should be rewritten with the
 following pseudo-code:

 {{{
 if the value is a number:
 return singular if value is 1 else plural
 if the value is a string:
 return singular if value is '1' else plural
 if the value has a length (needs a try/except TypeError):
 return singular if length is 1 else plural
 return ''
 }}}

 I discovered this while working on #16723.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16723: Pluralize filter shouldn't pluralize decimal/float values between 1 and 2

[Django]

#16723: Pluralize filter shouldn't pluralize decimal/float values between 1 and 
2
-+-
 Reporter:  rfugger  |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 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 aaugustin):

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


Comment:

 Re-reading the original report and the first comment closely, they
 actually say that all floats should trigger pluralization, even 1.0.

 This makes the `pluralize` filter unnecessary when used with floats.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19763: LocaleMiddleware should check for supported languages in settings.LANGUAGE_CODE too

[Django]

#19763: LocaleMiddleware should check for supported languages in
settings.LANGUAGE_CODE too
--+
 Reporter:  kozz  |Owner:  ambv
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  locale| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by lwarx):

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


Comment:

 I reported this issue in #19811 but the fix was superseded by this one and
 unfortunately missed 1.5 release. Is it possible to backport it to 1.5.x
 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 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19811: KeyError: u"Unknown language code 'en-us'."

[Django]

#19811: KeyError: u"Unknown language code 'en-us'."
--+
 Reporter:  lwarx |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Internationalization  |  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 lwarx):

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


Comment:

 It looks like patch was superseded by
 8c8f94fe9dcdd4983ebeb59951e6f7399bc287a2 in ticket #19763

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15039: The current download link redirection breaks wget making Linux download inconvenient

[Django]

#15039: The current download link redirection breaks wget making Linux download
inconvenient
-+-
 Reporter:  jonathanberger   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  *.djangoproject.com  |  Version:  1.2
 Severity:  Normal   |   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):

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


Comment:

 I thought this would be trivial to fix, but in fact it isn't, because it
 requires reversing to a different pattern, depending on the version.

 I've spent hours to find a workaround to what boils down to a bug in wget
 -- every other UA behaves properly; I give up.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19811: KeyError: u"Unknown language code 'en-us'."

[Django]

#19811: KeyError: u"Unknown language code 'en-us'."
--+
 Reporter:  lwarx |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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
--+

Comment (by lwarx):

 I hoped it would be included into 1.5 release... Is it possible to
 backport this fix to 1.5.x branch for next minor release?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.