Re: [Django] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
--+
   Reporter:  brutasse|Owner:  brutasse
 Status:  new |Milestone:  1.4
  Component:  Forms   |  Version:
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by poswald):

 * cc: poswald (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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+--
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+--

Comment (by grahamd):

 Technically, even in mod_python it was the wrong thing to be doing because
 Apache can supply output filters that are dependent on response content.
 For example, DEFLATE and CONTENT_LENGTH output filters.

-- 
Ticket URL: 
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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+--
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+--
Changes (by russellm):

 * stage:  Unreviewed => Accepted


Comment:

 Handling of HEAD requests is something that has been there from the
 beginning, so it's entirely likely that it's untested. As for the WSGI
 compliance -- it's never come up, so it. Django does drop the content for
 HEAD requests, so if that is the wrong thing to be doing (and based on
 Graham's comments, it looks like it might be in the WSGI context) there is
 a need for another ticket.

 By way of explanation -- In this case, I suspect Django's behavior
 predates our support for WSGI, and for mod_python, truncation would be
 (AFAICT) the right behavior.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+--
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+--

Comment (by j4mie):

 Interesting. I had no idea this was going to be a can of worms..

 I've attached a new patch which maintains the same simple `head = get`
 behaviour in the `View` class. I've simplified the tests to punt on
 checking that `response.content = ''` (just check that
 `response.status_code == 200`).

 I can't find any tests for the current handling of `HEAD` requests, so I'm
 not sure how much this behaviour has been thought through. Maybe this
 issue should be raised separately.

-- 
Ticket URL: 
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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+--
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+--

Comment (by grahamd):

 Python web applications should never themselves discard the response
 content for HEAD requests. They should always return the request content
 and allow the underlying WSGI server or hosting web server to discard the
 request content. If you don't do that and discard request content anyway,
 you violate the principal that GET and HEAD should return the same
 headers, because by removing the response content you prevent a WSGI
 middleware or web server output filter from processing response content
 and modifying the response headers. Go read
 'http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-
 requests.html'.

 So, if Django is already itself dropping response content for HEAD
 requests, it technically is not a well behaved WSGI application.

-- 
Ticket URL: 
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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+--
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+--
Changes (by j4mie):

 * version:  1.3-rc1 => 1.3


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+---
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3-rc1
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+---
Changes (by j4mie):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 I have added an initial patch, which probably needs improvement.

 1. Is the `as_view` method the correct place to add in the `head = get`
 patch?

 2. I had to make some changes to the tests to make this work. All the
 other tests in the `ViewTest` class use a `RequestFactory`, but I had to
 use the `TestClient` to make sure the content of the response was stripped
 correctly. This begs the question: should the content removal be done in
 the `View` class itself to prevent inconsistencies? Something like this
 maybe:

 {{{#!python
 def head_if_get(self, request, *args, **kwargs):
 # This method adds support for HEAD requests. If
 # a View subclass provides a get method, this method
 # is automatically aliased to head by as_view above.
 def remove_content(response):
 response.content = ''
 response = self.get(request, *args, **kwargs)
 if hasattr(response, 'add_post_render_callback'):
 response.add_post_render_callback(remove_content)
 else:
 remove_content(response)
 return response
 }}}

 Then

 {{{#!python
 if hasattr(self, 'get') and not hasattr(self, 'head'):
 self.head = self.head_if_get
 }}}

-- 
Ticket URL: 
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] #15672: wsgi handler bug in 1.3

[Django]

#15672: wsgi handler bug in 1.3
--+-
   Reporter:  vkryachko   |Owner:  vkryachko
 Status:  new |Milestone:
  Component:  Core framework  |  Version:  1.3
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+-
Changes (by russellm):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * version:  1.3-rc1 => 1.3
 * 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.

Re: [Django] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
--+
   Reporter:  brutasse|Owner:  brutasse
 Status:  new |Milestone:  1.4
  Component:  Forms   |  Version:
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by calvinspealman):

 * cc: ironfroggy@… (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] #1040: manage.py should have shebang and +x permissions

[Django]

#1040: manage.py should have shebang and +x permissions
---+--
   Reporter:  pb@… |Owner:  adrian
 Status:  reopened |Milestone:
  Component:  django-admin.py  |  Version:  SVN
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--

Comment (by ramiro):

 A couple of data points:

  * I can reproduce what the OP reports:
 `django/conf/project_template/manage.py` in the tree created by
 uncompressing an official tarball has excutable bits on.
  * `.../site-packages/django/conf/project_template/manage.py` has no
 executable bits; be it either by installing with `python setup.py install`
 from the uncompressed tarball or by running `pip install Django`, all this
 in a virtualenv.

 Do note that e.g. part one of the Tutorial uses `python manage.py
 ` but ther is an inconsistency regarding executable bits of
 manage.py has this inconsistency between a `startproject` done with e.g. a
 VCS checkout and with an official release installation.

 [http://docs.python.org/distutils/sourcedist.html Python docs] say nothing
 about executable permission of files that aren't listed in the `scripts`
 setup.py section. Perhaps it isn't possible at all?

-- 
Ticket URL: 
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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
--+
   Reporter:  brutasse|Owner:  brutasse
 Status:  new |Milestone:  1.4
  Component:  Forms   |  Version:
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by jezdez):

 * cc: jezdez (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] #1040: manage.py should have shebang and +x permissions

[Django]

#1040: manage.py should have shebang and +x permissions
---+--
   Reporter:  pb@… |Owner:  adrian
 Status:  reopened |Milestone:
  Component:  django-admin.py  |  Version:  SVN
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--

Comment (by lukeplant):

 Sorry, I can now see what you are talking about. However, I'm not sure
 this is a regression - having just checked Django 1.2 and 1.0, I don't
 think the executable bit has ever been set correctly 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.

Re: [Django] #1040: manage.py should have shebang and +x permissions

[Django]

#1040: manage.py should have shebang and +x permissions
---+--
   Reporter:  pb@… |Owner:  adrian
 Status:  reopened |Milestone:
  Component:  django-admin.py  |  Version:  SVN
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--
Changes (by anonymous):

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


Comment:

 Replying to [comment:3 lukeplant]:

 > The script is correct in the 1.3 tarball, and when you run `django-
 admin.py startproject` - I presume this must be a Ubuntu packaging bug.
 Please file a report with them. Thanks.

 You presume incorrectly - Ubuntu haven't produced a package yet - I was
 following the installation instructions as per:
 http://www.djangoproject.com/download/

 Searching for the manage.py in the unpacked directory shows...
 {{{
 -rw-r--r-- 1 root   root   503 2011-02-13 01:56 ./build/lib.linux-
 x86_64-2.6/django/conf/project_template/manage.py
 -rwxr-xr-x 1 adrian adrian 503 2011-02-13 01:56
 ./django/conf/project_template/manage.py
 }}}
 ...which looks as if the executable bit is being lost somewhere in the
 distutils script.

-- 
Ticket URL: 
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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+---
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3-rc1
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+---

Comment (by aaugustin):

 Django already strips the body of HEAD requests automatically, so head =
 get is enough.

 This is tangentially related to #15637.

-- 
Ticket URL: 
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] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |Owner:  dgouldin
  p.patruno@…|Milestone:
 Status:  new|  Version:  SVN
  Component: | Keywords:  inlines User
  django.contrib.admin   |  authentication
 Resolution: |Has patch:  0
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 I've just been bitten by this too, and have had to write a series of
 separate views to reimplement this part of the admin.

 In a way I'mg glad though because I realise my assumptions about how
 model-based permissions work were wrong. I had thought that adding
 permissions actually altered the model save() and delete() methods in some
 way – introducing the authentication check there. Is there a reason why
 that isn't a more appropriate place to do this kind of permission
 checking? Otherwise it feels like one is always dependent on the admin not
 to have bugs which mean the permissions aren't respected properly.

-- 
Ticket URL: 
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] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
-+-
   Reporter: |Owner:  dgouldin
  p.patruno@…|Milestone:
 Status:  new|  Version:  SVN
  Component: | Keywords:  inlines User
  django.contrib.admin   |  authentication
 Resolution: |Has patch:  0
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 I've just been bitten by this too, and have had to write a series of
 separate views to reimplement this part of the admin.

 In a way I'mg glad though because I realise my assumptions about how
 model-based permissions work were wrong. I had thought that adding
 permissions actually altered the model save() and delete() methods in some
 way – introducing the authentication check there. Is there a reason why
 that isn't a more appropriate place to do this kind of permission
 checking? Otherwise it feels like one is always dependent on the admin not
 to have bugs which mean the permissions aren't respected properly.

-- 
Ticket URL: 
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] #15666: Release notes link to development version of documentation

[Django]

#15666: Release notes link to development version of documentation
-+-
   Reporter:  Keryn  |Owner:  nobody
  Knight    |Milestone:
 Status:  closed |  Version:  SVN
  Component: | Keywords:  releasenotes
  Documentation  |Has patch:  0
 Resolution: |  Needs tests:  0
  worksforme |
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by Keryn Knight ):

 Yeah, I've just verified that's the way it's working, which is, I agree,
 how it should be; I think it's just the weblog linking to the dev version
 of the documentation that caused my confusion (and then clicking to each
 set of release notes from that caused me to go further down the rabbit
 hole).

-- 
Ticket URL: 
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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
--+
   Reporter:  brutasse|Owner:  brutasse
 Status:  new |Milestone:  1.4
  Component:  Forms   |  Version:
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by idangazit):

 * cc: idan@… (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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
--+
   Reporter:  brutasse|Owner:  brutasse
 Status:  new |Milestone:  1.4
  Component:  Forms   |  Version:
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by carljm):

 * cc: carl@… (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15666: Release notes link to development version of documentation

[Django]

#15666: Release notes link to development version of documentation
-+-
   Reporter:  Keryn  |Owner:  nobody
  Knight    |Milestone:
 Status:  closed |  Version:  SVN
  Component: | Keywords:  releasenotes
  Documentation  |Has patch:  0
 Resolution: |  Needs tests:  0
  worksforme |
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by gabrielhurley):

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


Comment:

 The way sphinx generates links, it will link to whatever version of the
 docs you are currently reading. For example:

  * If you are reading the 1.2 release notes in 1.3, all links will be to
 the 1.3 docs.
  * If you are reading the 1.1 release notes in the dev docs, all links
 will be to the dev version.

 and so on and so forth.

 In my mind, this is as it should be. I understand why this might be
 confusing to someone who arrived via google (which would take you to the
 1.3 docs by default) looking specifically for old information, but if
 you're looking for documentation on a specific older version it's made
 pretty obvious at the top of every page what version you're reading.

-- 
Ticket URL: 
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] #15673: Allow limit_choices_to to use a tuple for __in filters

[Django]

#15673: Allow limit_choices_to to use a tuple for __in filters
-+--
   Reporter:  EnTeQuAk   |Owner:  nobody
 Status:  new|Milestone:
  Component:  Uncategorized  |  Version:  SVN
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by EnTeQuAk):

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


Comment:

 sorry for the bad formatting...

 If one is to use `myfield = models.ForeignKey(MyModel,
 limit_choices_to={'valuein': ('one', 'two')})` this fails if rendered with
 `django.contrib.admin.widgets:url_params_from_lookup_dict`

 I attached a Diff that adds a unittest and the fix.

-- 
Ticket URL: 
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] #15673: Allow limit_choices_to to use a tuple for __in filters

[Django]

#15673: Allow limit_choices_to to use a tuple for __in filters
---+---
 Reporter:  EnTeQuAk   | Owner:  nobody
   Status:  new| Milestone:
Component:  Uncategorized  |   Version:  SVN
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  1  |
---+---
 If one is to use ``myfield = models.ForeignKey(MyModel,
 limit_choices_to={'value__in': ('one', 'two')})`` this fails if rendered
 with django.contrib.admin.widgets:url_params_from_lookup_dict

 I attached a Diff that adds a unittest and the fix.

-- 
Ticket URL: 
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] #15672: wsgi handler bug in 1.3

[Django]

#15672: wsgi handler bug in 1.3
+---
 Reporter:  vkryachko   | Owner:  vkryachko
   Status:  new | Milestone:
Component:  Core framework  |   Version:  1.3-rc1
 Keywords:  |  Triage Stage:  Unreviewed
Has patch:  0   |
+---
 When environ cannot be parsed, the following exception i raised:

 File "/var/www/dynamic/virtualenv/lib/python2.5/site-
 packages/django/core/handlers/wsgi.py", line 264, in __call__
  logger.warning('Bad Request (UnicodeDecodeError): %s' % request.path,
 UnboundLocalError: local variable 'request' referenced before assignment

-- 
Ticket URL: 
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] #15671: RemoteUserMiddleware hides true errors and exceptions

[Django]

#15671: RemoteUserMiddleware hides true errors and exceptions
--+---
   Reporter:  metzen  |Owner:
 Status:  new |Milestone:
  Component:  Authentication  |  Version:  SVN
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  1
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+---
Changes (by metzen):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #1040: manage.py should have shebang and +x permissions

[Django]

#1040: manage.py should have shebang and +x permissions
---+--
   Reporter:  pb@… |Owner:  adrian
 Status:  closed   |Milestone:
  Component:  django-admin.py  |  Version:  SVN
 Resolution:  fixed| Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--
Changes (by lukeplant):

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


Comment:

 The script is correct in the 1.3 tarball, and when you run `django-
 admin.py startproject` - I presume this must be a Ubuntu packaging bug.
 Please file a report with them. 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 this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15670: Doc issue: Some checking *is* performed on the SQL statement passed to raw()

[Django]

#15670: Doc issue: Some checking *is* performed on the SQL statement passed to
raw()
-+--
   Reporter:  dbreslau   |Owner:  nobody
 Status:  closed |Milestone:
  Component:  Documentation  |  Version:  1.2
 Resolution:  invalid| Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by Alex):

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


Comment:

 You've got a version sync issue, you're reading docs for a different
 version than the code, which no longer features such a check:
 http://code.djangoproject.com/changeset/15803

-- 
Ticket URL: 
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] #15671: RemoteUserMiddleware hides true errors and exceptions

[Django]

#15671: RemoteUserMiddleware hides true errors and exceptions
+---
 Reporter:  metzen  | Owner:  metzen
   Status:  new | Milestone:
Component:  Authentication  |   Version:  SVN
 Keywords:  |  Triage Stage:  Unreviewed
Has patch:  1   |
+---
 The !RemoteUserMiddleware hides true errors and exceptions that may occur
 when fetching Session and User data from the db backend.  This occurs
 because the middleware first performs a test to ensure that
 contrib.auth.middleware.!AuthenticationMiddleware has been installed by
 calling:

 {{{
 if not hasattr(request, 'user'):
 raise ImproperlyConfigured(...)
 }}}

 However, hasattr dangerously catches all exceptions that occur during the
 call, which hides any of the multitude of problems that could occur when
 the !LazyUser attribute attempts to fetch the real User instance from the
 database.

 I've proposed a patch which instead uses a try/except on !AttributeError
 to perform the same logic, while letting other exceptions correctly bubble
 up.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15670: Doc issue: Some checking *is* performed on the SQL statement passed to raw()

[Django]

#15670: Doc issue: Some checking *is* performed on the SQL statement passed to
raw()
-+--
   Reporter:  dbreslau   |Owner:  nobody
 Status:  new|Milestone:
  Component:  Documentation  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by dbreslau):

 * cc: dbreslau (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15670: Doc issue: Some checking *is* performed on the SQL statement passed to raw()

[Django]

#15670: Doc issue: Some checking *is* performed on the SQL statement passed to
raw()
---+---
 Reporter:  dbreslau   | Owner:  nobody
   Status:  new| Milestone:
Component:  Documentation  |   Version:  1.2
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 The doc page for Performing Raw Queries says:

  '''Warning'''

  No checking is done on the SQL statement that is passed in to .raw().
 Django expects that the statement will return a set of rows from the
 database, but does nothing to enforce that. If the query does not return
 rows, a (possibly cryptic) error will result.

 This isn't entirely true. In db/models/sql/query.py, the `RawQuery` class
 contains a method, `validate_sql`, that throws an exception if the
 statement doesn't begin with "SELECT".

 We'd actually rather it didn't do this check, as we'd like to be able to
 run an UPDATE...RETURNING (as supported by Oracle and PostgreSQL) via the
 raw query mechanism. But if it's going to do this, then the documentation
 should reflect the checking.

-- 
Ticket URL: 
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] #15669: Include app label in admin validation messages

[Django]

#15669: Include app label in admin validation messages
--+---
 Reporter:  lamby | Owner:  nobody
   Status:  new   | Milestone:
Component:  django.contrib.admin  |   Version:  SVN
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  1 |
--+---
 It is possible to have duplicate model names across your project (which is
 a good thing). However, it currently results in some ambiguous error
 messages when validating admin classes.

 For example:

{{{'MembershipAdmin.raw_id_fields' refers to field 'user_id' that is
 missing from model 'Membership'.}}}

 ... does that refer to my Membership class in my "foo" app or my "bar"
 app?

 The attached patch includes the app label in the error messages. For
 example:

{{{'MembershipAdmin.raw_id_fields' refers to field 'user_id' that is
 missing from model 'bar.Membership'.}}}

-- 
Ticket URL: 
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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
-+---
   Reporter:  j4mie  |Owner:  nobody
 Status:  new|Milestone:
  Component:  Generic views  |  Version:  1.3-rc1
 Resolution: | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+---
Changes (by j4mie):

 * needs_better_patch:   => 0
 * version:  1.2 => 1.3-rc1
 * needs_tests:   => 0
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15668: Generic views should provide a HEAD implementation

[Django]

#15668: Generic views should provide a HEAD implementation
---+---
 Reporter:  j4mie  | Owner:  nobody
   Status:  new| Milestone:
Component:  Generic views  |   Version:  1.2
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 Currently, HEAD requests are responded to with `405 METHOD NOT ALLOWED`
 and an `Allow: get` header.

 {{{
 $ curl -I localhost:8000
 HTTP/1.0 405 METHOD NOT ALLOWED
 Date: Wed, 23 Mar 2011 13:04:05 GMT
 Server: WSGIServer/0.1 Python/2.6.1
 Content-Type: text/html; charset=utf-8
 Allow: get
 }}}

 Generic views (or perhaps even the base View class?) should provide a
 `head()` implementation that should probably just call the `get` method
 (if present) and then throw away the content.

-- 
Ticket URL: 
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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
--+---
 Reporter:  brutasse  | Owner:  brutasse
   Status:  new   | Milestone:  1.4
Component:  Forms |   Version:
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 Following [https://groups.google.com/d/topic/django-
 developers/fMQnk2fAo_A/discussion this proposal on django-dev], this
 ticket tracks the status of replacing the widgets rendering code with a
 template-based system.

 The proposal is based on an existing implementation,
 [https://github.com/brutasse/django-floppyforms django-floppyforms]. The
 api provides several ways of extending a widget:

 * Widget.template_name: the name of the template used to render the widget
 * Widget.get_context_data(): a way to inject additional context data
 * Widget.get_context(name, value, attrs=None): this method calls
 get_context_data() and provides the basic context variables: attrs,
 hidden, name, required, type.

 I'm actively working on a patch and will attach it to the ticket as soon
 as I can so that the implementation and extension points can be discussed.

-- 
Ticket URL: 
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] #15666: Release notes link to development version of documentation

[Django]

#15666: Release notes link to development version of documentation
+---
 Reporter:  Keryn Knight   | Owner:  nobody
   Status:  new | Milestone:
Component:  Documentation   |   Version:  SVN
 Keywords:  releasenotes|  Triage Stage:  Unreviewed
Has patch:  0   |
+---
 The release notes for 1.3, 1.2, and 1.1 each rely on linking to the
 documentation regarding changes and improvements, but (possibly because of
 the way sphinx works?) instead of linking to the version specific
 documentation, they all lead to the /dev/ docs, which will obviously
 change after 1.3, and have certainly changed since 1.1 and 1.2 - this
 could make upgrading using the online docs as a guide more confusing than
 it otherwise would be, and leaves them historically accurate taken on
 their own, but not as part of overall documentation.

-- 
Ticket URL: 
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] #1040: manage.py should have shebang and +x permissions

[Django]

#1040: manage.py should have shebang and +x permissions
---+--
   Reporter:  pb@… |Owner:  adrian
 Status:  reopened |Milestone:
  Component:  django-admin.py  |  Version:  SVN
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--
Changes (by anonymous):

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


Comment:

 Regression: Django v1.3 release doesn't chmod +x the manage.py script.

 Environment: Ubuntu 10.x

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15665: Inline admins are broken when primary key is not an AutoField and not editable.

[Django]

#15665: Inline admins are broken when primary key is not an AutoField and not
editable.
--+---
 Reporter:  sebastian_noack   | Owner:  nobody
   Status:  new   | Milestone:
Component:  Database layer (models, ORM)  |   Version:  1.2
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 For each inline object, a hidden field for its primary key (if it is an
 AutoField) is included in the form. But if you inherit from a concrete
 model that has a custom (not AutoField) primary key, you end up in a
 situation where you have a primary key which is a OneToOneField that is
 not editable in the admin.

 {{{
 #!python
 from django.db import models

 class Event(models.Model):
 name = models.CharField(max_length=100, primary_key=True)

 def __unicode__(self):
 return self.name

 class Person(models.Model):
 name = models.CharField(max_length=100, primary_key=True)

 def __unicode__(self):
 return self.name

 class Visitor(Person):
 event = models.ForeignKey(Event)

 def __unicode__(self):
 return u"'%s' at '%s'" % (self.person_ptr, self.event)
 }}}

 {{{
 #!python
 from django.contrib import admin

 class VisitorInline(admin.StackedInline):
 model = Visitor

 class EventAdmin(admin.ModelAdmin):
 inlines = [VisitorInline]

 admin.site.register(Event, EventAdmin)
 }}}

 In that case there is no element in the form that holds the primary key
 and you get the Exception below, when you try to save an existing object
 in the admin.

 {{{
 Traceback (most recent call last):

   File
 "/home/sebastian/djacap/fam/src/famtest/django/core/servers/basehttp.py",
 line 280, in run
 self.result = application(self.environ, self.start_response)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/core/servers/basehttp.py",
 line 674, in __call__
 return self.application(environ, start_response)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/core/handlers/wsgi.py",
 line 241, in __call__
 response = self.get_response(request)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/core/handlers/base.py",
 line 141, in get_response
 return self.handle_uncaught_exception(request, resolver,
 sys.exc_info())

   File
 "/home/sebastian/djacap/fam/src/famtest/django/core/handlers/base.py",
 line 165, in handle_uncaught_exception
 return debug.technical_500_response(request, *exc_info)

   File "/home/sebastian/djacap/fam/src/famtest/django/views/debug.py",
 line 58, in technical_500_response
 html = reporter.get_traceback_html()

   File
 "/home/sebastian/djacap/fam/src/famtest/django/core/handlers/base.py",
 line 100, in get_response
 response = callback(request, *callback_args, **callback_kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/contrib/admin/options.py",
 line 239, in wrapper
 return self.admin_site.admin_view(view)(*args, **kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/utils/decorators.py", line
 76, in _wrapped_view
 response = view_func(request, *args, **kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/views/decorators/cache.py",
 line 69, in _wrapped_view_func
 response = view_func(request, *args, **kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/contrib/admin/sites.py",
 line 190, in inner
 return view(request, *args, **kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/utils/decorators.py", line
 21, in _wrapper
 return decorator(bound_func)(*args, **kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/utils/decorators.py", line
 76, in _wrapped_view
 response = view_func(request, *args, **kwargs)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/utils/decorators.py", line
 17, in bound_func
 return func(self, *args2, **kwargs2)

   File "/home/sebastian/djacap/fam/src/famtest/django/db/transaction.py",
 line 299, in _commit_on_success
 res = func(*args, **kw)

   File
 "/home/sebastian/djacap/fam/src/famtest/django/contrib/admin/options.py",
 line 890, in change_view
 queryset=inline.queryset(request))

   File "/home/sebastian/djacap/fam/src/famtest/django/forms/models.py",
 line 705, in __init__
 queryset=qs)

   File "/home/sebastian/djacap/fam/src/famtest/django/forms/models.py",
 line 429, in __init__
 super(BaseModelFormSet, self).__init__(**defaults)

   File "/home/sebastian/djacap/fam/src/famtest/django/forms/formsets.py",
 line 47, in __init__
 self._construct_forms()

   File "/home/sebastian/djacap/fam/src/famtest/django/forms/formsets.py",
 line 97, in _construct_forms
 self.forms.append(self._construct_form(i))

   File "/home/sebastian/djacap/fam/src/famtest/django/forms/models.py",
 line 718, in _construct_form
  

Re: [Django] #15624: aggregate produces incorrect sql statement

[Django]

#15624: aggregate produces incorrect sql statement
-+-
   Reporter:  zeroos |Owner:  nobody
  <232002@…> |Milestone:
 Status:  new|  Version:  SVN
  Component:  ORM| Keywords:  aggregate sql syntax
  aggregation|  error
 Resolution: |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * needs_docs:   => 0
 * component:  Database layer (models, ORM) => ORM aggregation
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15659: Contains lookups give wrong results on SQLite3 backend

[Django]

#15659: Contains lookups give wrong results on SQLite3 backend
-+-
   Reporter:  boxm   |Owner:  nobody
 Status:  new|Milestone:  1.3
  Component:  Database   |  Version:  SVN
  layer (models, ORM)| Keywords:  sqlite
 Resolution: |Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by boxm):

 * version:  1.3-alpha => SVN


Comment:

 Retested with 1.3-rc1 and behaviour is still present.

-- 
Ticket URL: 
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] #15663: Typo in release notes

[Django]

#15663: Typo in release notes
-+--
   Reporter:  adamv  |Owner:  nobody
 Status:  closed |Milestone:
  Component:  Documentation  |  Version:  SVN
 Resolution:  fixed  | Keywords:
   Triage Stage:  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by julien):

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


Comment:

 This typo wass fixd in [15908] ;)

-- 
Ticket URL: 
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] #15664: Unexpected brackets when describing commit_on_success

[Django]

#15664: Unexpected brackets when describing commit_on_success
-+--
   Reporter:  henryl |Owner:  nobody
 Status:  new|Milestone:
  Component:  Documentation  |  Version:  1.2
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by lrekucki):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * 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] #15664: Unexpected brackets when describing commit_on_success

[Django]

#15664: Unexpected brackets when describing commit_on_success
---+---
 Reporter:  henryl | Owner:  nobody
   Status:  new| Milestone:
Component:  Documentation  |   Version:  1.2
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 In the 'Controlling transaction management in views' section of the
 database transaction page
 (http://docs.djangoproject.com/en/dev/topics/db/transactions/#controlling-
 transaction-management-in-views) the decorator example is

 {{{
   #!python
   from django.db import transaction

   @transaction.commit_on_success()
   def viewfunc(request):
 ...
 }}}

 The '()' following commit_on_success shouldn't be there. It should be

 {{{
   #!python
   from django.db import transaction

   @transaction.commit_on_success
   def viewfunc(request):
 ...
 }}}

 In the actual 'commit_on_success' section
 
(http://docs.djangoproject.com/en/dev/topics/db/transactions/#django.db.transaction.commit_on_success)
 it is correctly used.

-- 
Ticket URL: 
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] #15662: module_has_submodule incorrectly uses the Importer Protocol

[Django]

#15662: module_has_submodule incorrectly uses the Importer Protocol
-+-
   Reporter:  Bradley|Owner:  nobody
  Ayers |Milestone:  1.3
 Status:  new|  Version:  1.2
  Component: | Keywords:
  Uncategorized  |Has patch:  1
 Resolution: |  Needs tests:  0
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by Alex):

 a) There's a typo in the patch, b) could use tests, c)  :)

-- 
Ticket URL: 
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] #15662: module_has_submodule incorrectly uses the Importer Protocol

[Django]

#15662: module_has_submodule incorrectly uses the Importer Protocol
-+-
   Reporter:  Bradley|Owner:  nobody
  Ayers |Milestone:  1.3
 Status:  new|  Version:  1.2
  Component: | Keywords:
  Uncategorized  |Has patch:  1
 Resolution: |  Needs tests:  0
   Triage Stage: |
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by lrekucki):

 * cc: lrekucki@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #15663: Typo in release notes

[Django]

#15663: Typo in release notes
---+---
 Reporter:  adamv  | Owner:  nobody
   Status:  new| Milestone:
Component:  Documentation  |   Version:  SVN
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+---
 http://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-the-login-
 methods-of-the-admin

 In the 2nd paragraph in this section, "This release refactores" should be
 "refactors".

-- 
Ticket URL: 
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] #15662: module_has_submodule incorrectly uses the Importer Protocol

[Django]

#15662: module_has_submodule incorrectly uses the Importer Protocol
-+---
 Reporter:  Bradley Ayers   | Owner:  nobody
   Status:  new  | Milestone:  1.3
Component:  Uncategorized|   Version:  1.2
 Keywords:   |  Triage Stage:  Unreviewed
Has patch:  1|
-+---
 django.utils.module_loading.module_has_submodule has the code:

 {{{
 for finder in sys.meta_path:
 if finder.find_module(name):
 return True
 }}}

 where `name` is the absolute path to the module that should be imported.
 However PEP302 that defines the Importer Protocol says that a second
 argument must be supplied if the module isn't directly on `sys.path`.

 Thus, the code should be:

 {{{
 for finder in sys.meta_path:
 if finder.find_module(name, package):
 return True
 }}}

 I came across this problem with using Attest, Django, and loading a
 template tag that had the same name as a package on my PATH.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.