Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+-
 Reporter:  pixelcort|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  1
-+-
Changes (by Li Meng ):

 * cc: liokmkoil@… (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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18468: Define COMMENT in table / colomns

[Django]

#18468: Define COMMENT in table / colomns
-+-
 Reporter:  mrechte  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by niwi):

 * cc: niwi@… (added)
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 I've implemented initial implementatio for postgresql_psycopg2 backend:
 https://github.com/niwibe/django/compare/issue_18468

 Is only implemented the table comment sql.

 If accepted as a new feature, would be nice to make design decisions.
 Today I put the comment for table in class "Meta", another option is to
 use the first line of the model docstrings.

 For fields, is more simple, just add an optional parameter "comment" at
 the Field.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18582: Emails not being sent to bcc addresses

[Django]

#18582: Emails not being sent to bcc addresses
---+--
 Reporter:  javi.azuaga@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  bcc, mail  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Please do not reopen unless you can provide something new to the problem.
 The console backend won't show Bcc addresses, as it uses the
 message.as_string() method which doesn't contain the Bcc recipients.

 There are other reasons that might prevent some receiver to receive a
 message. In this case, it is probably not Django's fault, unless you can
 prove us the contrary.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18130: postgres_psycopg2 adapter should not use hard coded isolation levels

[Django]

#18130: postgres_psycopg2 adapter should not use hard coded isolation levels
-+-
 Reporter:  limscoder|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  postgres |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by niwi):

 * cc: niwi@… (added)
 * has_patch:  0 => 1


Comment:

 Here the patch to allow to define the default isolation_level parameter on
 database configuracion dict:
 https://github.com/niwibe/django/compare/issue_18130

 I ran the tests (not all tests) and I have not seen any fail that might be
 related.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[django/django] 24dec9: Add reST role to templates named in some view docs...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 24dec9edaac7849c7831ff0ee4245b6637a9639e
  
https://github.com/django/django/commit/24dec9edaac7849c7831ff0ee4245b6637a9639e
  Author: Ben Spaulding 
  Date:   2012-06-26 (Tue, 26 Jun 2012)

  Changed paths:
M django/contrib/comments/views/moderation.py
M django/contrib/comments/views/utils.py
M django/contrib/flatpages/views.py
M django/views/defaults.py

  Log Message:
  ---
  Add reST role to templates named in some view docs.

This makes the templates link up correctly in the admindocs.


  Commit: 8855f9380e93d759eea93c32cdf25b76b72e15c4
  
https://github.com/django/django/commit/8855f9380e93d759eea93c32cdf25b76b72e15c4
  Author: Adrian Holovaty 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M django/contrib/comments/views/moderation.py
M django/contrib/comments/views/utils.py
M django/contrib/flatpages/views.py
M django/views/defaults.py

  Log Message:
  ---
  Merge pull request #176 from benspaulding/ticket_18521

Add reST role to templates named in some view docs.


Compare: https://github.com/django/django/compare/70ac57015773...8855f9380e93

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[django/django] 3caf53: fixed typo

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3caf53524c5285f1a057e00fc6549cde0ca67dda
  
https://github.com/django/django/commit/3caf53524c5285f1a057e00fc6549cde0ca67dda
  Author: Renato Pedigoni 
  Date:   2012-07-04 (Wed, 04 Jul 2012)

  Changed paths:
M docs/releases/1.5.txt

  Log Message:
  ---
  fixed typo


  Commit: 70ac5701577379ef33402ccd0b2a302145ddb56f
  
https://github.com/django/django/commit/70ac5701577379ef33402ccd0b2a302145ddb56f
  Author: Adrian Holovaty 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M docs/releases/1.5.txt

  Log Message:
  ---
  Merge pull request #183 from rpedigoni/master

Fixed typo in 1.5 release notes


Compare: https://github.com/django/django/compare/4e8084a4cb67...70ac57015773

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[django/django] 83da36: restored a missing \ in uwsgi docs

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 83da36ebfbdad2ac6e714b5308c076a1fb64b0be
  
https://github.com/django/django/commit/83da36ebfbdad2ac6e714b5308c076a1fb64b0be
  Author: Daniele Procida 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M docs/howto/deployment/wsgi/uwsgi.txt

  Log Message:
  ---
  restored a missing \ in uwsgi docs


  Commit: 4e8084a4cb67c42c64c279408bc46bdeb82f6ccc
  
https://github.com/django/django/commit/4e8084a4cb67c42c64c279408bc46bdeb82f6ccc
  Author: Adrian Holovaty 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M docs/howto/deployment/wsgi/uwsgi.txt

  Log Message:
  ---
  Merge pull request #187 from evildmp/docs_typos

Added a missing \ in uwsgi docs. Thanks, evildmp.


Compare: https://github.com/django/django/compare/7151fbd0787b...4e8084a4cb67

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[django/django] 91e4f7: Fix copyright holder

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 91e4f7effb6c0911d2db68c9f17b40f484838538
  
https://github.com/django/django/commit/91e4f7effb6c0911d2db68c9f17b40f484838538
  Author: Guilherme Gondim 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M django/utils/baseconv.py

  Log Message:
  ---
  Fix copyright holder


  Commit: 7151fbd0787be6aa14fd778c017bfe2f856e44ae
  
https://github.com/django/django/commit/7151fbd0787be6aa14fd778c017bfe2f856e44ae
  Author: Adrian Holovaty 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M django/utils/baseconv.py

  Log Message:
  ---
  Merge pull request #188 from semente/patch-1

Fixed copyright holder in baseconf.py.


Compare: https://github.com/django/django/compare/2ba4278cb38f...7151fbd0787b

-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18582: Emails not being sent to bcc addresses

[Django]

#18582: Emails not being sent to bcc addresses
---+--
 Reporter:  javi.azuaga@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  bcc, mail  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by javi.azuaga@…):

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


Comment:

 Actually the real email addresses that should receive BCCs copies doesn't
 get the messages.
 This happends on the production machine(webfaction) and even on the
 development machine, using the Console backend, only 1 message is shown
 instead of a message for every address on msg.receivers(). I've checked
 this last method and the result is as expected, the TO address and the BCC
 addresses.

 The posted code is just a quick example to easy the reproduction of the
 problem and triage of the problem, as I thought the BCC field should
 appear somewhere on the headers at least on the Console backend. Sorry if
 that confused the 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15506: Savepoint support for sqlite3 backend

[Django]

#15506: Savepoint support for sqlite3 backend
-+-
 Reporter:  lamby|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by niwi):

 I think you should go deprecating older versions of sqlite to equal what
 is being done with support for versions of python. And take advantage of
 the new things that are incorporated 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 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15506: Savepoint support for sqlite3 backend

[Django]

#15506: Savepoint support for sqlite3 backend
-+-
 Reporter:  lamby|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by niwi):

 * cc: niwi@… (added)


Comment:

 I could not find the official announcement, but according to the
 documentation of APSW:
 > Savepoints were introduced in SQLite 3.6.8
 (http://apidoc.apsw.googlecode.com/hg/pysqlite.html#what-apsw-does-better)

 I've done my own tests, comments in the code that clarify some things that
 I found and contrasting with official documentation of sqlite and
 pysqlite: https://gist.github.com/3061376

 This case is very similar to #14204, the difference is the minimum version
 of 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 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18585: Tutorial part 4: problem in polls/detail.html

[Django]

#18585: Tutorial part 4: problem in polls/detail.html
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anonymous):

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


Comment:

 Nevermind... looks like it changed since I started the tutorial.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18585: Tutorial part 4: problem in polls/detail.html

[Django]

#18585: Tutorial part 4: problem in polls/detail.html
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In Writing your first Django app, part 4:
 https://docs.djangoproject.com/en/1.4/intro/tutorial04/

 Near the top of the page, the text for polls/detail.html
 has a problem.

 In the for loop to create the form, choice.choice is used
 for the text of the choices, but choice.choice_text is
 really what is needed 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13008: @never_cache decorator should add 'no-cache' & 'must-revalidate'

[Django]

#13008: @never_cache decorator should add  'no-cache' & 'must-revalidate'
-+
 Reporter:  harm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  1.2-beta
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by eykd):

 Shouldn't this also set the `Pragma: no-cache` header?

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18538: type(SimpleLazyObject) returns SimpleLazyObject rather than type(_wrapped)

[Django]

#18538: type(SimpleLazyObject) returns SimpleLazyObject rather than 
type(_wrapped)
-+-
 Reporter:  jdunck   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 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 lukeplant):

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


Comment:

 I also suspect there is nothing that can be done. Other approaches to
 making `request.user` lazy:

 1. Dynamically add something to the request class e.g. a user property.
 This causes problems with tests because you are mutating global state - we
 tried this before, and changed to `SimpleLazyObject` because of this
 problem.
 2. Using `lazy` - doesn't work because you don't know the type of user. It
 could be a third party class returned by a custom authentication backend.

 So I'm going to resolve as WONTFIX for now, but anyone with bright ideas
 for fixing this is welcome to re-open.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18552: Django test client should not use MULTIPART_CONTENT for POST-requests by default.

[Django]

#18552: Django test client should not use MULTIPART_CONTENT for POST-requests by
default.
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by lukeplant):

 Why shouldn't it send multipart content by default? I believe it makes it
 easier to send files, and changing might require lots of fixes to any test
 code that sends files.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18553: Django multipart parser creates mutable QueryDict

[Django]

#18553: Django multipart parser creates mutable QueryDict
---+
 Reporter:  k_bx   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  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 lukeplant):

 * stage:  Unreviewed => Accepted


Comment:

 I haven't tested, but it sounds plausible.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18584: Ability to fetch urlname from template context

[Django]

#18584: Ability to fetch urlname from template context
-+--
 Reporter:  foxwhisper   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by lukeplant):

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


Comment:

 I don't see any need for this to be in core, it can be added easily as
 context processor.  (In fact it can **only** be added using a context
 processor, since Templates can be used without a request object being
 current, and we are currently avoiding putting the request into any
 threadlocals).

 Although it may be common for you do use this technique, I've never
 actually had this requirement myself, so I don't think you can argue it is
 so common that it should be on by default.

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

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

Re: [Django] #18577: Undocumented lazy middleware initialization

[Django]

#18577: Undocumented lazy middleware initialization
--+
 Reporter:  makuro@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  middleware, settings  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by lukeplant):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * component:  Core (Other) => Documentation
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 There isn't really a 'startup' event at the moment. Resolving on first
 request makes most sense, especially for the case where you might not be
 serving requests at all. It doesn't make sense to initialize until you
 need to use it. So I'm going to mark this as docs bug.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18582: Emails not being sent to bcc addresses

[Django]

#18582: Emails not being sent to bcc addresses
---+--
 Reporter:  javi.azuaga@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Mail)|  Version:  1.4
 Severity:  Normal |   Resolution:  invalid
 Keywords:  bcc, mail  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by lukeplant):

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


Comment:

 BCC works fine for me, tested on Django 1.4 on a live server. We added BCC
 support in [5ff1d96a52] and fixed a bug in [319a31464d], so this has
 indeed been working for other people for a long time.

 The output on the console is exactly what you would expect - the BCC
 addresses are not listed (that's what BCC means).

 I've checked the SMTP code for sending, and it correctly sends the same
 email (without the BCC addresses) to all recipients (which includes all TO
 and BCC addresses). This is how SMTP works. Regarding your MTA logs, I
 don't know if it is evidence of a bug or not - it depends whether the 'to'
 listed is the 'to' address on the email or the contents of the 'RCPT TO'
 SMTP header.

 (You mentioned the default 'IMAP' backend - I presume you meant SMTP).

 Anyway, there is nothing reported that confirms that the emails are not in
 fact being sent. Have you actually tried for real and found that BCCs are
 not being sent? If so, are you sure that some other system is not
 swallowing them?

 I'm going to close as INVALID for now, on the assumption that this is just
 based on a mistake about how SMTP works. Please re-open if the emails are
 not being sent, and there is a genuine bug in Django and you can provide
 information that will allow us to track it down.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18245: Error in documentation of date based generic views

[Django]

#18245: Error in documentation of date based generic views
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  new
Component:  Documentation  |  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 aaugustin):

 I see you've written a patch. I'm just assigning the ticket to myself in
 order to review it and 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18484: csrfmiddlewaretoken enclosed in redundant invisible div

[Django]

#18484: csrfmiddlewaretoken enclosed in redundant invisible div
---+
 Reporter:  hedleyroos@…   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  fixed
 Keywords:  csrf   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Luke Plant ):

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


Comment:

 In [2ba4278cb38f1346d70cf427bbeac71a4d1dc5ad]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ba4278cb38f1346d70cf427bbeac71a4d1dc5ad"
 Fixed #18484 - 'display:none' on CSRF token div is redundant and causes
 problems with some browsers

 Thanks to hedleyroos for the report
 }}}

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

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

[django/django] 2ba427: Fixed #18484 - 'display:none' on CSRF token div is...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 2ba4278cb38f1346d70cf427bbeac71a4d1dc5ad
  
https://github.com/django/django/commit/2ba4278cb38f1346d70cf427bbeac71a4d1dc5ad
  Author: Luke Plant 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M django/template/defaulttags.py

  Log Message:
  ---
  Fixed #18484 - 'display:none' on CSRF token div is redundant and causes 
problems with some browsers

Thanks to hedleyroos for the report



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

Re: [Django] #18557: get_or_create() causes a race condition with MySQL

[Django]

#18557: get_or_create() causes a race condition with MySQL
-+-
 Reporter:  foxwhisper   |Owner:  nobody
 Type:  Uncategorized|   Status:  reopened
Component:  Database layer   |  Version:  1.4
  (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
-+-
Changes (by foxwhisper):

 * cc: cal@… (added)
 * component:  Core (URLs) => Database layer (models, ORM)


-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18557: get_or_create() causes a race condition with MySQL

[Django]

#18557: get_or_create() causes a race condition with MySQL
---+--
 Reporter:  foxwhisper |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  Core (URLs)|  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by foxwhisper):

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


Comment:

 @akaariai You raise a very good point about it breaking transaction
 control, and enabling such a flag would depend on the developer ensuring
 they knew exactly what they were doing, and when it is safe to use it.

 I'm thinking something along these lines:

 {{{
 MyModel.objects.get_or_create(a=1, b=2, force_commit=True)
 }}}

 Along with a documentation update that says:

 {{{
 Certain databases (such as MySQL) don't gracefully handle get_or_create()
 when multiple threads are being used to write
 to the same table. If throughput is high enough, then there is a small
 race condition where the MySQL index says the
 unique index exists, but any attempt to fetch that key will result in
 failure.

 The only way around this is to commit the transaction you are in, which
 then allows you to fetch the row. However, if
 your get_or_create() is in a transaction block with manual commits, then
 any queries before the get_or_create() call
 will also be committed.

 If you plan on using this feature, you must ensure that the
 get_or_create() call is within a safe context where it is
 okay for the previous queries to be committed.
 }}}

 Also, to touch on your question about what kind of usage pattern leads to
 this race condition, it's fairly easy to trigger. You just need two or
 more threads attempting to perform get_or_create() on the same table,
 within a close space of each other. A typical scenario could be a queued
 import job which has to do a get_or_create() on a popular item such as IP
 address. If both scripts encounter the same IP at the same time, it will
 cause the race condition to happen. The reason this affected us so badly,
 is because the majority of our work involves importing and mangling large
 data sets - where as a low traffic site would almost never see this
 happen.

 If the above suggested patch description sounds good, please let me know
 and I'll get a patch prepared.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

[Django]

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-+-
 Reporter:  sebastian_noack  |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:  mysql transaction|  Patch needs improvement:  1
  isolation  |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by foxwhisper):

 * cc: cal@… (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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13906: REPEATABLE READ (as used by default on MySQL) breaks atleast QuerySet.get_or_create().

[Django]

#13906: REPEATABLE READ (as used by default on MySQL) breaks atleast
QuerySet.get_or_create().
-+-
 Reporter:  sebastian_noack  |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:  mysql transaction|  Patch needs improvement:  1
  isolation  |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by foxwhisper):

 I can confirm that using READ COMMITED transaction isolation can cause
 lots of other problems..

 See related ticket:
 https://code.djangoproject.com/ticket/18557

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18245: Error in documentation of date based generic views

[Django]

#18245: Error in documentation of date based generic views
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  new
Component:  Documentation  |  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 mateusgondim):

 Hi, sorry, did i do something wrong?

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18584: Ability to fetch urlname from template context

[Django]

#18584: Ability to fetch urlname from template context
-+
 Reporter:  foxwhisper   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Template system  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Currently to detect what the current urlname is in a template requires
 adding some code into each view. This is so you can detect what page you
 are currently on, to place for example CSS classes onto a link to indicate
 you are on that page.

 Really, Django should have the urlname in the request context as standard.
 I'm currently using the following approach:

 {{{

 context_processors.py:
 def resolve_urlname(request):
 """Allows us to see what the matched urlname for this
 request is within the template"""
 from django.core.urlresolvers import resolve
 try:
 res = resolve(request.path)

 if res:
 return {'urlname' : res.url_name}
 except:
 return {}
 }}}


 {{{
 URL CONF:
 url(r'^$', "sites.vf.views.home", name = "home"),
 }}}


 This then allows me to do things like this:
 {{{
 
 }}}

 Essentially, it allows you to keep all aspects of managing a sites URLs
 within the same code set and forces the same naming convention.

 Could a core developer please confirm if such a patch would be accepted
 into the core? I feel there's a strong case for this.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18583: exclude generates wrong SQL query

[Django]

#18583: exclude generates wrong SQL query
--+
 Reporter:  rbreu |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:  query exclude
 Triage Stage:  Unreviewed|  sql
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 exclude generates a wrong SQL query in a certain setup. Given the
 following models:

 {{{#!python
 class A(models.Model):
 pass

 class AGroups(models.Model):
 a = models.ForeignKey(A, related_name='groups')
 group = models.ForeignKey(Group)

 class B(models.Model):
 a = models.ForeignKey(A)

 class C(models.Model):
 b = models.ForeignKey(B)
 }}}

 Then the following:

 {{{#!python
 g = Group.objects.create(name='foo')
 C.objects.exclude(b__a__groups__group__in=[g])
 }}}

 generates the following query:

 {{{
 SELECT "books_c"."id", "books_c"."name", "books_c"."b_id" FROM "books_c"
 INNER JOIN "books_b" ON ("books_c"."b_id" = "books_b"."id")
 INNER JOIN "books_a" ON ("books_b"."a_id" = "books_a"."id")
 WHERE NOT (("books_b"."a_id" IN (
 SELECT U1."id" FROM "books_b" U1
 INNER JOIN "books_a" U2 ON (U1."a_id" = U2."id")
 INNER JOIN "books_agroups" U3 ON (U2."id" = U3."a_id")
 WHERE (U3."group_id" IN (3) AND U1."id" IS NOT NULL)
   )
 AND "books_a"."id" IS NOT NULL)) LIMIT 21
 }}}

 Line 4 should be

 {{{
 WHERE NOT (("books_b"."id" IN (
 }}}

 instead.

 The same issue happens with

 {{{#!python
 agroups = AGroups.objects.filter(group__in=[g])
 C.objects.exclude(b__a__groups__in=agroups)
 }}}

 This one works:

 {{{#!python
 b_excludes = B.objects.filter(a__groups__group__in=[g])
 C.objects.exclude(b__in=b_excludes)
 }}}


 (Using Django 1.4, Python 2.7.3rc2, sqlite)


 See attachment for more testing 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18581: Admin actions documentation needs a new screenshot

[Django]

#18581: Admin actions documentation needs a new screenshot
---+
 Reporter:  msopacua   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  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:  1  |UI/UX:  0
---+
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18582: Emails not being sent to bcc addresses

[Django]

#18582: Emails not being sent to bcc addresses
---+---
 Reporter:  javi.azuaga@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Core (Mail)|Version:  1.4
 Severity:  Normal |   Keywords:  bcc, mail
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 First things first: this is the first bug I report, so please excuse me
 and point me in the right direction if I'm making something wrong.

 Now, to the bug. Sending an email with both EmailMessage and
 EmailMultiAlternatives to BCC addresses fails.
 I've tried this on my development machine (Archlinux), on a fresh Kubuntu
 12.04 virtualbox install and on a Webfaction server, both with the default
 IMAP backend and the Console backend, with Python 2.7 and both Django 1.3
 and 1.4 installed both on fresh virtualenvs and then removed and installed
 as system packages.

 I experience this problem on several big proyects as well as on fresh
 project with just a view.

 This is the simplest code test I've make and it's output to the Console
 backend:

 views.py:
 {{{
 from django.core.mail import EmailMessage, EmailMultiAlternatives
 from django.http import HttpResponse

 def index(request):

 msg = EmailMessage(
 subject='test',
 to=['m...@example.org'],
 bcc=['nowh...@example.org'],
 body='test'
 )
 msg.send()

 msg = EmailMultiAlternatives(
 subject='test',
 to=['m...@example.org'],
 bcc=['nowh...@example.org'],
 body='test'
 )
 msg.send()

 return HttpResponse("Testing...")
 }}}

 Output for both Django 1.4 and 1.3, notice how bcc doesn't appear:

 {{{
 Content-Type: text/plain; charset="utf-8"
 MIME-Version: 1.0
 Content-Transfer-Encoding: quoted-printable
 Subject: test
 From: webmaster@localhost
 To: m...@example.org
 Date: Fri, 06 Jul 2012 12:26:54 -
 Message-ID: <20120706122654.9417.52070@i5-750>

 test
 ---
 Content-Type: text/plain; charset="utf-8"
 MIME-Version: 1.0
 Content-Transfer-Encoding: quoted-printable
 Subject: test
 From: webmaster@localhost
 To: m...@example.org
 Date: Fri, 06 Jul 2012 12:26:54 -
 Message-ID: <20120706122654.9417.77135@i5-750>

 test
 ---
 [06/Jul/2012 07:26:54] "GET / HTTP/1.1" 200 10
 }}}

 This is the output of the MTA from webfaction's log:

 {{{
 Jul 5 11:15:56 mail6 postfix/smtpd[24001]: 1A216210E8AE:
 client=web317.webfaction.com[85.17.23.88], sasl_method=CRAM-MD5,
 sasl_username=batl...@smtp.webfaction.com
 Jul 5 11:15:56 mail6 postfix/cleanup[23507]: 1A216210E8AE: message-
 id=<20120705161555.19081.91...@web317.webfaction.com>
 Jul 5 11:15:56 mail6 postfix/qmgr[3022]: 1A216210E8AE:
 from=, size=1416, nrcpt=1 (queue
 active)
 Jul 5 11:16:26 mail6 postfix/smtp[23745]: 1A216210E8AE:
 to=, relay=none, delay=30, delays=0.39/0/30/0,
 dsn=4.4.1, status=deferred (connect to example.org[192.0.43.10]:
 Connection timed out)
 Jul 5 11:46:05 mail6 postfix/qmgr[3022]: 1A216210E8AE:
 from=, size=1416, nrcpt=1 (queue
 active)
 Jul 5 11:47:00 mail6 postfix/smtp[25697]: 1A216210E8AE:
 to=, relay=none, delay=1864, delays=1809/25/30/0,
 dsn=4.4.1, status=deferred (connect to example.org[192.0.43.10]:
 Connection timed out)
 Jul 5 12:19:22 mail6 postfix/qmgr[3022]: 1A216210E8AE:
 from=, size=1416, nrcpt=1 (queue
 active)
 Jul 5 12:20:02 mail6 postfix/smtp[27946]: 1A216210E8AE:
 to=, relay=none, delay=3847, delays=3806/10/30/0,
 dsn=4.4.1, status=deferred (connect to example.org[192.0.43.10]:
 Connection timed out)
 Jul 5 13:26:00 mail6 postfix/qmgr[3022]: 1A216210E8AE:
 from=, size=1416, nrcpt=1 (queue
 active)
 Jul 5 13:27:00 mail6 postfix/smtp[4785]: 1A216210E8AE:
 to=, relay=none, delay=7864, delays=7804/30/30/0,
 dsn=4.4.1, status=deferred (connect to example.org[192.0.43.10]:
 Connection timed out)
 Jul 5 14:49:20 mail6 postfix/qmgr[3022]: 1A216210E8AE:
 from=, size=1416, nrcpt=1 (queue
 active)
 Jul 5 14:50:08 mail6 postfix/smtp[16526]: 1A216210E8AE:
 to=, relay=none, delay=12853, delays=12804/18/30/0,
 dsn=4.4.1, status=deferred (connect to example.org[192.0.43.10]:
 Connection timed out)
 Jul 5 16:12:40 mail6 postfix/qmgr[3022]: 1A216210E8AE:
 from=, size=1416, nrcpt=1 (queue
 active)
 Jul 5 16:13:40 mail6 postfix/smtp[23562]: 1A216210E8AE:
 to=, relay=none, delay=17864, delays=17804/30/30/0,
 dsn=4.4.1, status=deferred (connect to 

Re: [Django] #18576: Missing module in import statement

[Django]

#18576: Missing module in import statement
---+
 Reporter:  jaaruiz@…  |Owner:  claudep
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  fixed
 Keywords:  wrong example  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Claude Paroz ):

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


Comment:

 In [4c417cc9ebd65595128b81cdddc9ea8293cbcbbe]:
 {{{
 #!CommitTicketReference repository=""
 revision="4c417cc9ebd65595128b81cdddc9ea8293cbcbbe"
 Fixed #18576 -- Added missing import in tutorial02

 Thanks jaaruiz at yahoo.com for the report.
 }}}

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

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

[django/django] 4c417c: Fixed #18576 -- Added missing import in tutorial02

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4c417cc9ebd65595128b81cdddc9ea8293cbcbbe
  
https://github.com/django/django/commit/4c417cc9ebd65595128b81cdddc9ea8293cbcbbe
  Author: Claude Paroz 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M docs/intro/tutorial02.txt

  Log Message:
  ---
  Fixed #18576 -- Added missing import in tutorial02

Thanks jaaruiz at yahoo.com for the report.



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

Re: [Django] #18576: Missing module in import statement

[Django]

#18576: Missing module in import statement
---+
 Reporter:  jaaruiz@…  |Owner:  claudep
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  wrong example  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by claudep):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => claudep
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Old description:

> A necessary module is not being imported in one of the examples. The
> example is located at
> https://docs.djangoproject.com/en/dev/intro/tutorial02/
>
> The example code is as follows:
>
> from django.contrib import admin
> from polls.models import Poll
>
> class ChoiceInline(admin.StackedInline):
> model = Choice
> extra = 3
>
> class PollAdmin(admin.ModelAdmin):
> fieldsets = [
> (None,   {'fields': ['question']}),
> ('Date information', {'fields': ['pub_date'], 'classes':
> ['collapse']}),
> ]
> inlines = [ChoiceInline]
>
> admin.site.register(Poll, PollAdmin)
>

>

>
> The second line of the code should also import the `Choice' model as
> follows:
> from polls.models import Poll, Choice

New description:

 A necessary module is not being imported in one of the examples. The
 example is located at
 https://docs.djangoproject.com/en/dev/intro/tutorial02/

 The example code is as follows:
 {{{
 from django.contrib import admin
 from polls.models import Poll

 class ChoiceInline(admin.StackedInline):
 model = Choice
 extra = 3

 class PollAdmin(admin.ModelAdmin):
 fieldsets = [
 (None,   {'fields': ['question']}),
 ('Date information', {'fields': ['pub_date'], 'classes':
 ['collapse']}),
 ]
 inlines = [ChoiceInline]

 admin.site.register(Poll, PollAdmin)
 }}}


 The second line of the code should also import the `Choice' model as
 follows:
 from polls.models import Poll, Choice

--

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18575: Testing framework doesn't work without a SQL Database

[Django]

#18575: Testing framework doesn't work without a SQL Database
---+
 Reporter:  delormemarco@… |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.4
 Severity:  Release blocker|   Resolution:
 Keywords:  regression | 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):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * keywords:   => regression
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18581: Admin actions documentation needs a new screenshot

[Django]

#18581: Admin actions documentation needs a new screenshot
---+
 Reporter:  msopacua   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 https://docs.djangoproject.com/en/1.4/_images/article_actions.png

 Code above the image states:
 make_published.short_description = "Mark selected stories as published"

 Image shows a select drop-down with the text: 'Make published'

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18574: `BaseFormSet.is_valid` should call it's underlying forms' `is_valid`

[Django]

#18574: `BaseFormSet.is_valid` should call it's underlying forms' `is_valid`
-+-
 Reporter:  charettes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  form formset | Triage Stage:  Accepted
  is_valid   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_tests:  0 => 1
 * 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18543: Non image file can be saved to ImageField

[Django]

#18543: Non image file can be saved to ImageField
-+-
 Reporter:  johnsmith|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Unreviewed => Accepted


Comment:

 Currently, the verification that the content is an image is done by the
 `ImageField` form field (see its `to_python` method), not in the model
 field.

 Accepted on the base that we should at least:
   * Improve the error message as shown in the previous comment.
   * Clarify the documentation

 Validating that the file is really an image file at the model level might
 be something to evaluate, but with great care, because of the performance
 issue involved by this operation. Opinions/design decision needed 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5579: Trac activation mail is sent from 'webmaster@localhost'

[Django]

#5579: Trac activation mail is sent from 'webmaster@localhost'
-+-
 Reporter:  tback|Owner:  anonymous
 Type:  Bug  |   Status:  closed
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  activation email |  Needs documentation:  0
  trac   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Please don't reopen ticket without providing any explanations.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18245: Error in documentation of date based generic views

[Django]

#18245: Error in documentation of date based generic views
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  new
Component:  Documentation  |  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):

 * owner:  mateusgondim => aaugustin


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

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

[Django] #18580: Avoiding SQLite update+annotations "only a single result allowed for a SELECT that is part of an expression"

[Django]

#18580: Avoiding SQLite update+annotations "only a single result allowed for a
SELECT that is part of an expression"
--+
 Reporter:  jonash|  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When executing something like

 {{{
 Foo.objects.annotate(bar_count=Count('bars')) \
.update(spam=42)
 }}}

 SQLite throws an `only a single result allowed for a SELECT that is part
 of an expression` error.

 This can be worked around using `.values('id')`:


 {{{
 Foo.objects.annotate(bar_count=Count('bars')) \
.values('id') \
.update(spam=42)
 }}}

 Looks like SQLite can't cope with multiple fields in the `SELECT` clause,
 so I suggest not `SELECT`ing all the fields if we don't need them anyways
 (as in this case).

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[django/django] 86eb60: Used skipIf decorator to skip image tests when PIL...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 86eb606b88b3979de8074c3a049535150a0cc8a5
  
https://github.com/django/django/commit/86eb606b88b3979de8074c3a049535150a0cc8a5
  Author: Claude Paroz 
  Date:   2012-07-06 (Fri, 06 Jul 2012)

  Changed paths:
M tests/regressiontests/model_fields/imagefield.py
M tests/regressiontests/model_fields/tests.py

  Log Message:
  ---
  Used skipIf decorator to skip image tests when PIL is not available



-- 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18579: Wimbledon finals tonight

[Django]

#18579: Wimbledon finals tonight
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 A [http://www.replicawatches-discount.com/rolex-c354 rolex replica] watch
 is obviously a treasure, and now we get the [http://www.replicawatches-
 discount.com/omega-c50 omega replica] is very different.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #18578: More chopsticks there

[Django]

#18578: More chopsticks there
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you are feeling worried of dressing up [http://www.replicawatches-
 discount.com/ replica watches] yourself because of a party, you really do
 not want to open [http://www.replicawatches-discount.com/breitling-c21
 breitling replica]s in public.

-- 
Ticket URL: 
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 this group at 
http://groups.google.com/group/django-updates?hl=en.