[Django] #19306: Docs: simple example does not work

[Django]

#19306: Docs: simple example does not work
---+
 Reporter:  brycenesbitt   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Implementing 'A simple example' at
 https://docs.djangoproject.com/en/dev/ref/contrib/syndication/

 Gives error
 '''Give your Entry class a get_absolute_url() method, or define an
 item_link() method in your Feed class.'''

 Due to a missing 'def item_link(self, item):'

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

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

Re: [Django] #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:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Preston Holmes ):

 In [changeset:"44046e8a38225067d4d0feac35367eeae133446a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="44046e8a38225067d4d0feac35367eeae133446a"
 Fixed #18985 -- made DeprecationWarnings loud

 Capture warnings in Python >= 2.7 and route through
 console handler, which is subject to DEBUG==True

 Thanks to dstufft for the idea, and claudep for initial patch
 }}}

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

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

[django/django] 44046e: Fixed #18985 -- made DeprecationWarnings loud

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 44046e8a38225067d4d0feac35367eeae133446a
  
https://github.com/django/django/commit/44046e8a38225067d4d0feac35367eeae133446a
  Author: Preston Holmes 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/conf/__init__.py
M django/utils/log.py
M docs/releases/1.5.txt
M tests/regressiontests/logging_tests/tests.py

  Log Message:
  ---
  Fixed #18985 -- made DeprecationWarnings loud

Capture warnings in Python >= 2.7 and route through
console handler, which is subject to DEBUG==True

Thanks to dstufft for the idea, and claudep for initial patch



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

[django/django] 0d49fd: [1.5.x] Fixed #18985 -- made DeprecationWarnings l...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 0d49fdb573d44794cc78c6af4761cc79c5330315
  
https://github.com/django/django/commit/0d49fdb573d44794cc78c6af4761cc79c5330315
  Author: Preston Holmes 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/conf/__init__.py
M django/utils/log.py
M docs/releases/1.5.txt
M tests/regressiontests/logging_tests/tests.py

  Log Message:
  ---
  [1.5.x] Fixed #18985 -- made DeprecationWarnings loud

Capture warnings in Python >= 2.7 and route through
console handler, which is subject to DEBUG==True

Thanks to dstufft for the idea, and claudep for initial patch



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

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:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Preston Holmes ):

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


Comment:

 In [changeset:"0d49fdb573d44794cc78c6af4761cc79c5330315"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0d49fdb573d44794cc78c6af4761cc79c5330315"
 [1.5.x] Fixed #18985 -- made DeprecationWarnings loud

 Capture warnings in Python >= 2.7 and route through
 console handler, which is subject to DEBUG==True

 Thanks to dstufft for the idea, and claudep for initial patch
 }}}

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

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

[django/django] cefbf0: [1.5.X] Fixed docs noting comment_will_be_sent ret...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: cefbf09a4d17ac1f5a90c9a8e68b21bfdd973d31
  
https://github.com/django/django/commit/cefbf09a4d17ac1f5a90c9a8e68b21bfdd973d31
  Author: Brandon Adams 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/contrib/comments/signals.py
M docs/ref/contrib/comments/signals.txt

  Log Message:
  ---
  [1.5.X] Fixed docs noting comment_will_be_sent returns a 400, not a 403

Backport of d8ee46afff from master



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

[django/django] d8ee46: comment_will_be_sent can cause a 400, not a 403

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d8ee46afff913975404887cdd2eec635a03013f8
  
https://github.com/django/django/commit/d8ee46afff913975404887cdd2eec635a03013f8
  Author: Brandon Adams 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/contrib/comments/signals.py
M docs/ref/contrib/comments/signals.txt

  Log Message:
  ---
  comment_will_be_sent can cause a 400, not a 403

Doc cleanup for django.contrib.comments.signals.comment_will_be_sent
If a receiver returns False, an HttpResponse with status code 400
is returned. A test case already exists confirming this behavior.
Updated docs to reflect reality.


  Commit: b4a98e028adb5b32dcfa7384e46f57b28b43b684
  
https://github.com/django/django/commit/b4a98e028adb5b32dcfa7384e46f57b28b43b684
  Author: Tim Graham 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/contrib/comments/signals.py
M docs/ref/contrib/comments/signals.txt

  Log Message:
  ---
  Merge pull request #521 from emidln/master

Fixed docs noting comment_will_be_sent signals return 400 status code


Compare: https://github.com/django/django/compare/ff0d3126afbc...b4a98e028adb

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

Re: [Django] #18866: model Meta verbose_name too long error message not obvious

[Django]

#18866: model Meta verbose_name too long error message not obvious
--+
 Reporter:  elena |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 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 aaugustin):

 * component:  Database layer (models, ORM) => contrib.auth
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Yes, I've hit that several times myself. It's annoying. syncdb crashes
 because it tries to create a permission with a name that's longer than 50
 characters.

 Possible solutions:
 - improve the error message
 - display a warning and truncate the value
 - increase the size of the field to 200 characters (insert usual rant
 about lack of migrations in core here)

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

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

Re: [Django] #19137: runserver child started via autoreload won't always exit cleanly

[Django]

#19137: runserver child started via autoreload won't always exit cleanly
-+-
 Reporter:  santtu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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

Re: [Django] #19264: prefetch_one_level is slow

[Django]

#19264: prefetch_one_level is slow
-+-
 Reporter:  simonpercivall   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Design decision needed


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

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

Re: [Django] #19076: TemplateView does not support setting mime type, like views.generic.simple.direct_to_template did

[Django]

#19076: TemplateView does not support setting mime type, like
views.generic.simple.direct_to_template did
---+
 Reporter:  gwahl@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

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

Re: [Django] #19282: intcomma for decimal no longer works as expected

[Django]

#19282: intcomma for decimal no longer works as expected
-+-
 Reporter:  judy |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  contrib.humanize |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  intcomma, humanize,  |  Needs documentation:  0
  decimal|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 This is a side effect of
 
[https://github.com/django/django/commit/8f3e1c1c63d3d3b36715afa9095e04142c4507e2#L3L30
 the fix for #6392].

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

Re: [Django] #19251: Normalize newlines from Textarea widgets

[Django]

#19251: Normalize newlines from Textarea widgets
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | 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):

 Replying to [comment:3 claudep]:
 > If browsers would systematically return CRLF, you would be right. But
 this isn't always true, so the situation is already inconsistent and
 somewhat broken.

 I didn't explain it well, but my reasoning was:
 - regular requests always use CRLF: if we normalize to CRLF, we're
 backwards compatible, if we normalize to LF, we aren't.
 - AJAX requests are browser dependent: no matter which way we normalize,
 it will have side effects for some people.

 In my opinion this is a basic browser interoperability issue that is
 better left to browser developers / W3C / etc.; but if you're keen on
 fixing it in Django that's just fine.

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

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

Re: [Django] #19251: Normalize newlines from Textarea widgets

[Django]

#19251: Normalize newlines from Textarea widgets
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | 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 claudep):

 Replying to [comment:2 aaugustin]:
 > If browsers generally send CRLF and we want to normalize, shouldn't we
 normalize to CRLF — even if our personal tastes are different — to avoid
 creating regressions for Windows users? For instance if they're building
 text files from user input, suddenly their files may not display correctly
 any longer.

 If browsers would systematically return CRLF, you would be right. But this
 isn't always true, so the situation is already inconsistent and somewhat
 broken.

 > Generally speaking, Django is very careful about not altering data sent
 by the browsers. For instance it doesn't strip whitespace, even though
 it's a very common request, and it's the right thing to do 99% of the
 time.

 Stripping whitespace is semantically altering content, as leading/trailing
 space may be wanted and significant (albeit seldom). Changing new line
 format does not change the content (still semantically speaking), this is
 only a technical artefact.

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

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

Re: [Django] #19019: UserAdmin.user_change_password does not log the change

[Django]

#19019: UserAdmin.user_change_password does not log the change
--+
 Reporter:  Tuttle|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 I reproduced the issue.

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

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

Re: [Django] #19001: only+annotate+selected_related is broken

[Django]

#19001: only+annotate+selected_related is broken
-+-
 Reporter:  jiaji|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  needsinfo
 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
-+-
Changes (by aaugustin):

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


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

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

Re: [Django] #19251: Normalize newlines from Textarea widgets

[Django]

#19251: Normalize newlines from Textarea widgets
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | 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):

 * easy:  1 => 0
 * stage:  Unreviewed => Design decision needed


Comment:

 If browsers generally send CRLF and we want to normalize, shouldn't we
 normalize to CRLF — even if our personal tastes are different — to avoid
 creating regressions for Windows users? For instance if they're building
 text files from user input, suddenly their files may not display correctly
 any longer.

 Generally speaking, Django is very careful about not altering data sent by
 the browsers. For instance it doesn't strip whitespace, even though it's a
 very common request, and it's the right thing to do 99% of the time.

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

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

Re: [Django] #19270: makemessages and compilemessages force the location of PO files

[Django]

#19270: makemessages and compilemessages force the location of PO files
-+-
 Reporter:  julen|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:
Component:  Core (Management |   Resolution:  needsinfo
  commands)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  gettext, l10n,   |  Needs documentation:  0
  i18n, makemessages,|  Patch needs improvement:  0
  compilemessages|UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Indeed, `LC_MESSAGES/` isn't designed to hold PO files. But it's been
 working well until now!

 What layout would you suggest?  What's the value in making the location
 configurable?

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

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

Re: [Django] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
-+
 Reporter:  svsharma@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  ORM aggregation  |  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 aaugustin):

 #19290 is a duplicate.

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

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

Re: [Django] #19290: 'exclude' on aggregations makes wrong SQL

[Django]

#19290: 'exclude' on aggregations makes wrong SQL
-+--
 Reporter:  letscan@…|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  ORM aggregation  |  Version:  1.4
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  aggregation  | Triage Stage:  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
 * needs_better_patch:   => 0
 * component:  Database layer (models, ORM) => ORM aggregation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => duplicate


Comment:

 This looks exactly like #14971 and #10060. Please reopen if it's a
 different issue. 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19293: Update of czech date and time formats

[Django]

#19293: Update of czech date and time formats
---+
 Reporter:  vzima  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Translations   |  Version:  1.4
 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 aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Marking as accepted; we're just waiting for the translation of the
 conclusion of the discussion.

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

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

Re: [Django] #19295: runserver --insecure doesn't work with DEBUG False and CachedStaticFilesStorage

[Django]

#19295: runserver --insecure doesn't work with DEBUG False and
CachedStaticFilesStorage
-+-
 Reporter:  Apreche  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 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 aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I can reproduce the issue, but I don't know how to fix it.

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

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

Re: [Django] #19300: capfirst filter breaks translation context in template

[Django]

#19300: capfirst filter breaks translation context in template
-+-
 Reporter:  dyve |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  trans context|  worksforme
  capfirst   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 I can't reproduce the issue on master.

 With this template and the appropriate French translations:
 {{{
 {% trans "species" %}
 # works as expected, results in translation of 'species'

 {% trans "species" context "singular" %}
 # works as expected, results in translation of 'species' with context
 'singular'

 {% trans "species"|capfirst %}
 # works as expected, results in translation of 'species' without context,
 capfirst applied

 {% trans "species"|capfirst context "singular" %}
 # works as expected, results in translation of 'species' with context
 'singular', capfirst applied
 }}}
 I get this output:
 {{{
 espèces # works as expected, results in translation of 'species'

 espèce # works as expected, results in translation of 'species' with
 context 'singular'

 Espèces # works as expected, results in translation of 'species' without
 context, capfirst applied

 Espèce # works as expected, results in translation of 'species' with
 context 'singular', capfirst applied
 }}}

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

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

Re: [Django] #19302: Add option to disable Admin log (LogEntry)

[Django]

#19302: Add option to disable Admin log (LogEntry)
-+-
 Reporter:  shadow   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:
 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 aaugustin):

 * easy:  1 => 0
 * stage:  Unreviewed => Design decision needed


Comment:

 I'm hesitating to accept this request.

 Our [https://docs.djangoproject.com/en/dev/internals/contributing/bugs-
 and-features/#requesting-features contributing guidelines] recommend
 sending feature requests to the [https://groups.google.com/group/django-
 developers django-developers] mailing list. Could you start a discussion
 to see if there's support for this idea?

 Please include a link to the discussion in the comments.

 PS: the quick'n'dirty way to achieve this is to hook to the `post_delete`
 signal to clean up related log entries.

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

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

Re: [Django] #19303: ModelAdmin.formfield_overrides is ignored for fields with choices

[Django]

#19303: ModelAdmin.formfield_overrides is ignored for fields with choices
---+
 Reporter:  bendavis78 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I assume you meant:

 {{{
  formfield_overrides = {
  MyCustomField: {'widget': MyCustomWidget}
  }
 }}}

 The patch isn't acceptable because it breaks a test:

 {{{
 (django-dev)myk@mYk tests % PYTHONPATH=.. ./runtests.py
 --settings=test_sqlite admin_widgets
 ~/Documents/dev/django/tests
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 ..Fsss...sss...
 ==
 FAIL: testFieldWithChoices
 (regressiontests.admin_widgets.tests.AdminFormfieldForDBFieldTests)
 --
 Traceback (most recent call last):
   File
 "/Users/myk/Documents/dev/django/tests/regressiontests/admin_widgets/tests.py",
 line 116, in testFieldWithChoices
 self.assertFormfield(models.Member, 'gender', forms.Select)
   File
 "/Users/myk/Documents/dev/django/tests/regressiontests/admin_widgets/tests.py",
 line 58, in assertFormfield
 (model.__class__.__name__, fieldname, widgetclass, type(widget))
 AssertionError: Wrong widget for ModelBase.gender: expected , got 

 --
 Ran 41 tests in 0.430s

 FAILED (failures=1, skipped=6)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

 

 For consistency between `formfield_for_choice_field`,
 `formfield_for_foreignkey` and `formfield_for_manytomany`, the fix should
 move the handling of `formfield_overrides` either up, at the beginning of
 `formfield_for_dbfield`, or down, in a common method that would wrap
 `db_field.formfield` and be called by each `formfield_to_*`. Actually it
 would have to do both, see below.

 The expected order of precendence is:
 - `formfield_overrides`
 - values set by `formfield_for_*`
 - FORMFIELD_FOR_DBFIELD_DEFAULTS

 This can't be achieved without some refactoring,
 because`formfield_overrides` is currently merged with
 `FORMFIELD_FOR_DBFIELD_DEFAULTS`.

 This code dates back to f212b24b6469b66424354bf970f3051df180b88d.

 Here's how I would fix the problem:
 - merge `formfield_overrides` in `kwargs` at the very beginning of
 `formfield_for_dbfield`
 - add a wrapper around that merges `FORMFIELD_FOR_DBFIELD_DEFAULTS` in
 `kwargs` and then calls `db_field.formfield`
 - write tests.

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

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

Re: [Django] #19304: the mistake of the QuerySet Caching

[Django]

#19304: the mistake of the QuerySet Caching
-+-
 Reporter:  rex@…|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  QuerySet Caching,|  Unreviewed
  Models get |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 No, `get_query_set()` is only creating a new QuerySet instance.

 Please don't use the ticket system for usage question (see
 TicketClosingReasons/UseSupportChannels).

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

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

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  jacob|Owner:  konk
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  database |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kkumler):

 * cc: kkumler (added)


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

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

[Django] #19305: Spotify Premium Code

[Django]

#19305: Spotify Premium Code
---+--
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:  Spotify Premium Code
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 [http://up2datenews.net/spotify-premium-code-daily-update/ Spotify Premium
 Code]

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

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

[Django] #19304: the mistake of the QuerySet Caching

[Django]

#19304: the mistake of the QuerySet Caching
-+-
 Reporter:  rex@…|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  1.4
  (models, ORM)  |   Keywords:  QuerySet Caching,
 Severity:  Normal   |  Models get
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 hi Django Team,

 may be I get some problem by following to django docs, in programe the
 Models logic,
 the docs notice that get method get()
 https://docs.djangoproject.com/en/dev/ref/models/querysets/#get  '''do not
 use a cache (see Caching and QuerySets). Rather, they query the database
 each time they're called.''' but when in fact I check the source
 '''/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py'''
 line 130

 def get(self, *args, **kwargs):
  return self.get_query_set().get(*args, **kwargs)


 the method is use the cache of the querySet , and I need some help to know
 How do I use a query get() DO NOT Use a Cache, thanks many, btw sorry
 about my English.

 Rex

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

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

Re: [Django] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:  pegler@… |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sqlite spatialite| Triage Stage:  Accepted
  LiveServerTestCase |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Claude Paroz ):

 In [changeset:"b39b0aedbfbddf8fab0c43b92dc237caa8da375f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b39b0aedbfbddf8fab0c43b92dc237caa8da375f"
 [1.5.x] Fixed #19296 -- Applied test connection sharing for spatialite

 Thanks pegler at gmail.com for the report and the initial patch.
 Backport of ff0d3126af from master.
 }}}

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

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

[django/django] b39b0a: [1.5.x] Fixed #19296 -- Applied test connection sh...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: b39b0aedbfbddf8fab0c43b92dc237caa8da375f
  
https://github.com/django/django/commit/b39b0aedbfbddf8fab0c43b92dc237caa8da375f
  Author: Claude Paroz 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/test/testcases.py

  Log Message:
  ---
  [1.5.x] Fixed #19296 -- Applied test connection sharing for spatialite

Thanks pegler at gmail.com for the report and the initial patch.
Backport of ff0d3126af from master.



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

Re: [Django] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:  pegler@… |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sqlite spatialite| Triage Stage:  Accepted
  LiveServerTestCase |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"ff0d3126afbc30ae1aab3a9d352300e59937fe5e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff0d3126afbc30ae1aab3a9d352300e59937fe5e"
 Fixed #19296 -- Applied test connection sharing for spatialite

 Thanks pegler at gmail.com for the report and the initial patch.
 }}}

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

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

[django/django] ff0d31: Fixed #19296 -- Applied test connection sharing fo...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ff0d3126afbc30ae1aab3a9d352300e59937fe5e
  
https://github.com/django/django/commit/ff0d3126afbc30ae1aab3a9d352300e59937fe5e
  Author: Claude Paroz 
  Date:   2012-11-16 (Fri, 16 Nov 2012)

  Changed paths:
M django/test/testcases.py

  Log Message:
  ---
  Fixed #19296 -- Applied test connection sharing for spatialite

Thanks pegler at gmail.com for the report and the initial patch.



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

Re: [Django] #19296: LiveServerTestCase does not share connection to sqlite if using spatialite

[Django]

#19296: LiveServerTestCase does not share connection to sqlite if using 
spatialite
-+-
 Reporter:  pegler@… |Owner:  claudep
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite spatialite| Triage Stage:  Accepted
  LiveServerTestCase |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * owner:  pegler => claudep


Comment:

 I'm not convinced this needs testing. Thanks for your patch, I will commit
 something soon.

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

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

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Unfortunately the patch does have too much going on for one patch. I could
 rewrite it to smaller pieces, but I am not sure if the effort-reward ratio
 is there.

 The changes aren't _that_ big. The patch changes around 250 lines of
 django core code, and a large part of those changes are reindent of the
 model._meta traversal code.

 The tests did pass and I have a confident feeling that the patch is doing
 the right thing. However I am not going to push this forward today. I have
 been doing too many mistakes lately (#13781 did need a few tries, and I
 just did the equivalent of DELETE * FROM tbl in a production DB...). So, I
 will do something completely else for a couple of days and then revisit
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:  akaariai
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by milosu):

 I've spent some time looking at the latest source code with this patch
 applied, but the changes are really very big for me to be able to make any
 usefull review (without spending a few weeks).

 Anyway - the new code looks to be more readable than the old one, so if
 everything passes tests, I think you can commit it.

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

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

Re: [Django] #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:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Just in case this wan't clear, the latest patch I uploaded on this ticket
 only outputs anything when DEBUG is True (by default), as the `console`
 logging handler is filtered by `require_debug_true`. Of course, this is
 all configurable by a custom logging config.

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

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