[Django] #10913: Default related_name is broken

[Django]

#10913: Default related_name is broken
--+-
 Reporter:  neithere  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  orm, related_name,|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The documentation [http://docs.djangoproject.com/en/dev/topics/db/queries
 /#backwards-related-objects states] that by default the "backward"
 relationship Manager ''"is named {{{FOO_set}}}, where {{{FOO}}} is the
 source model name, lowercased"''. However, in the latest SVN snapshot the
 behaviour seems to be inconsistent.

 '''models.py'''

 {{{
 from django.db import models

 class Author(models.Model):
 name = models.CharField(max_length=255)

 class Book(models.Model):
 title  = models.CharField(max_length=255)
 author = models.ForeignKey(Author) # by default,
 related_name='book_set'

 }}}

 The {{{related_name}}} argument is commented out. If not, everything works
 fine, but let's see what happens now:

 '''In shell after syncdb:'''

 {{{
 >>> from fooapp.models import Author, Book
 >>> Author.book_set
 
 >>> Author.book
 Traceback (most recent call last):
   File "", line 1, in 
 AttributeError: type object 'Author' has no attribute 'book'
 >>> a=Author.objects.create(name='John')
 >>> b=Book.objects.create(title='My Book', author=a)
 >>> Author.objects.filter(book_set__exact=1)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.1_beta_1-py2.6.egg/django/db/models/manager.py", line
 129, in filter
 return self.get_query_set().filter(*args, **kwargs)
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.1_beta_1-py2.6.egg/django/db/models/query.py", line 466,
 in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.1_beta_1-py2.6.egg/django/db/models/query.py", line 484,
 in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.1_beta_1-py2.6.egg/django/db/models/sql/query.py", line
 1613, in add_q
 can_reuse=used_aliases)
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.1_beta_1-py2.6.egg/django/db/models/sql/query.py", line
 1511, in add_filter
 negate=negate, process_extras=process_extras)
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.1_beta_1-py2.6.egg/django/db/models/sql/query.py", line
 1676, in setup_joins
 "Choices are: %s" % (name, ", ".join(names)))
 FieldError: Cannot resolve keyword 'book_set' into field. Choices are:
 book, id, name
 >>> Author.objects.filter(book__exact=1)
 []
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10912: firstof template tag should autoescape variables

[Django]

#10912: firstof template tag should autoescape variables
--+-
  Reporter:  andrewbadr   | Owner:  andrewbadr
Status:  new  | Milestone:
 Component:  Template system  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by andrewbadr):

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

Comment:

 My expected behavior for Django is: The results of all template tags
 should be escaped unless marked safe. For builtin templatetags that return
 safe strings, this should include escaping any variables involved in
 rendering that template tag.

 The included patch solves locally what I see as part of a bigger problem.

-- 
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] #10912: firstof template tag should autoescape variables

[Django]

#10912: firstof template tag should autoescape variables
-+--
 Reporter:  andrewbadr   |   Owner:  andrewbadr
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 I'd expect firstof to escape variables.

-- 
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] #7401: Documentation should note potential problems with SELinux

[Django]

#7401: Documentation should note potential problems with SELinux
+---
  Reporter:  user1274   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution:  invalid|  Keywords:  install mod_python selinux
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

Comment:

 I think we've decided not to include too many distro-specific notes in the
 official docs, so I've put these notes on the
 [http://code.djangoproject.com/wiki/Distributions#SELinux Distributions
 page] of the Django Wiki.

-- 
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] #9983: Javascript issue on admin interface with prepopulated_fields

[Django]

#9983: Javascript issue on admin interface with prepopulated_fields
---+
  Reporter:  msurdi| Owner:  kkubasik
Status:  new   | Milestone:  1.1 
 Component:  django.contrib.admin  |   Version:  1.0 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 The following is also another similar patch for this issue:
 http://code.djangoproject.com/ticket/9110

-- 
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] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
--+-
  Reporter:  fas  | Owner:  fas 

Status:  new  | Milestone:  1.1 

 Component:  ORM aggregation  |   Version:  SVN 

Resolution:   |  Keywords:  orm, aggregation, join, 
contenttypes, filter
 Stage:  Accepted | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * milestone:  => 1.1

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10817: grammar in forms section

[Django]

#10817: grammar in forms section
--+-
  Reporter:  nickretall...@gmail.com  | Owner:  nobody  
Status:  new  | Milestone:  
 Component:  Documentation|   Version:  SVN 
Resolution:   |  Keywords:  typo grammar
 Stage:  Ready for checkin| Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by timo):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * version:  1.0 => SVN
  * keywords:  => typo grammar
  * needs_docs:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Ready for checkin

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

Re: [Django] #10901: auth.contrib silently catching TypeError

[Django]

#10901: auth.contrib silently catching TypeError
-+--
  Reporter:  anonymous   | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 Replying to [comment:1 ramiro]:
 > Replying to [ticket:10901 anonymous]:
 > > - Why not fail as early as possible if one of the authentication
 > > backends configured in settings.py has a wrong signature? If nothing
 > > else at least a warning should be logged IMHO.
 >
 > Because, for example,
 `django.contrib.auth.backends.ModelBackend.authenticate()` has both
 ''user'' and ''password'' parameters and
 `django.contrib.auth.backends.RemoteUserBackend.authenticate()` has just
 one ''user'' parameter.

 Supporting multiple authentication backends is good, but I don't think
 that the implementations is the best. Please see the related discussion on
 Django-Users:

 http://groups.google.com.au/group/django-
 users/browse_thread/thread/27076627b7c35e43/7c49a7b61325120b#7c49a7b61325120b

-- 
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] #2507: [patch] LDAPBackend in django/contrib/auth/backends.py

[Django]

#2507: [patch] LDAPBackend in django/contrib/auth/backends.py
---+
  Reporter:  s...@mahonri5.net  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:  ldap,usernames
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  1 |  
---+
Changes (by hcarvalhoalves):

 * cc: hcarvalhoal...@gmail.com (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] #10911: Date comparison lookup operators

[Django]

#10911: Date comparison lookup operators
---+
  Reporter:  vbmendes  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  lookup, 
orm, date
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Old description:

> It would be nice to have lookup operators such as day_gt, day_gte,
> day_lt, day_lte, month_gt, month_gte, month_lt and month_lte. With this,
> we will be able to do comparisons such as date__month_gt=6 to find
> objects with the date object in the second semester, and much more good
> things. The lookups are:
>
> * day_lt -- day lower then;
> * day_gt -- day greather then;
> * day_lte -- day lower then or equal;
> * day_gte -- day greather then or equal;
> * day_range -- accepts a tuple or list with two elements, just like the
> range loopup operator;
>
> And the same thing for month, year and week_day.

New description:

 It would be nice to have lookup operators such as {{{ day_gt }}}, {{{
 day_gte }}}, {{{ day_lt }}}, {{{ day_lte }}}, {{{ month_gt }}}, {{{
 month_gte }}}, {{{ month_lt }}} and {{{ month_lte }}}. With this, we will
 be able to do comparisons such as {{{ date__month_gt=6 }}} to find objects
 with the date object in the second semester, and much more good things.
 The lookups are:

  * {{{ day_lt }}} -- day lower then;
  * {{{ day_gt }}} -- day greather then;
  * {{{ day_lte }}} -- day lower then or equal;
  * {{{ day_gte }}} -- day greather then or equal;
  * {{{ day_range }}} -- accepts a tuple or list with two elements, just
 like the range loopup operator;

 And the same thing for month, year and week_day.

Comment:

 Please use preview.

-- 
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] #10911: Date comparison lookup operators

[Django]

#10911: Date comparison lookup operators
--+-
 Reporter:  vbmendes  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  lookup, orm, date |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 It would be nice to have lookup operators such as day_gt, day_gte, day_lt,
 day_lte, month_gt, month_gte, month_lt and month_lte. With this, we will
 be able to do comparisons such as date__month_gt=6 to find objects with
 the date object in the second semester, and much more good things. The
 lookups are:

 * day_lt -- day lower then;
 * day_gt -- day greather then;
 * day_lte -- day lower then or equal;
 * day_gte -- day greather then or equal;
 * day_range -- accepts a tuple or list with two elements, just like the
 range loopup operator;

 And the same thing for month, year and week_day.

-- 
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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner: 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Changes (by hcarvalhoalves):

 * cc: hcarvalhoal...@gmail.com (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] #10896: UrlField cannot be used with relative URLs

[Django]

#10896: UrlField cannot be used with relative URLs
---+
  Reporter:  notanumber| Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  url 
urlfield relative
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by dc):

 That behaviour was specially added in #5331 by the core developer so this
 ticket looks like 'wontfix'.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10910: Unicode dictionary keys cause TypeError when used as arguments to filter()

[Django]

#10910: Unicode dictionary keys cause TypeError when used as arguments to 
filter()
---+
  Reporter:  mostrovsky| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 By the way, the reason that #10645 is a bug and this isn't is because in
 #10645 Django itself was creating the dictionary and needed to construct
 it properly. In this case, the user is constructing the dictionary
 themselves and can do the right thing in the first place.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10910: Unicode dictionary keys cause TypeError when used as arguments to filter()

[Django]

#10910: Unicode dictionary keys cause TypeError when used as arguments to 
filter()
---+
  Reporter:  mostrovsky| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 This isn't a bug with Django. You can only use the str type for parameter
 names when calling Python functions. That applies for kwargs as well. It's
 normal Python behaviour and you should get into the habit of only using
 str objects as the keys in dictionaries passed as kwargs. So the solution
 to your problem is "don't do that".

-- 
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] #10910: Unicode dictionary keys cause TypeError when used as arguments to filter()

[Django]

#10910: Unicode dictionary keys cause TypeError when used as arguments to 
filter()
---+
  Reporter:  mostrovsky| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * needs_better_patch:  => 0
  * version:  1.0 => SVN
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Change Version field value to SVN as per ticket description.

-- 
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] #10907: Adding google news sitemap support to django.contrib.sitemaps

[Django]

#10907: Adding google news sitemap support to django.contrib.sitemaps
---+
  Reporter:  lakinwecker   | Owner:  lakinwecker
Status:  assigned  | Milestone: 
 Component:  Contrib apps  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by lakinwecker):

 Ok, those bugs have been ferretted out.

-- 
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] #10909: Django Sitemaps Framework does not allow the use of the Domain Settings Site

[Django]

#10909: Django Sitemaps Framework does not allow the use of the Domain Settings
Site
---+
  Reporter:  qingfeng  | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Contrib apps  |   Version:  1.0 
Resolution:|  Keywords:  sitemaps
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by qingfeng):

 Replying to [comment:1 Tarken]:
 > I won't close this myself, as I have no official word in the development
 of Django... but this appears to be invalid.
 >
 > DOMAIN is not a setting which is currently set or used anywhere else in
 Django. Nor does it appear to really be necessary. Django can't account
 for every setting that you may add to your project.

 :)To do so is to facilitate, as some projects with less than a database,
 the current code can not output the Sitemap

-- 
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] #10907: Adding google news sitemap support to django.contrib.sitemaps

[Django]

#10907: Adding google news sitemap support to django.contrib.sitemaps
---+
  Reporter:  lakinwecker   | Owner:  lakinwecker
Status:  assigned  | Milestone: 
 Component:  Contrib apps  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by lakinwecker):

  * owner:  nobody => lakinwecker
  * status:  new => assigned

Comment:

 There are a couple of small bugs that i discovered this morning - working
 through those now.

-- 
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] #10909: Django Sitemaps Framework does not allow the use of the Domain Settings Site

[Django]

#10909: Django Sitemaps Framework does not allow the use of the Domain Settings
Site
---+
  Reporter:  qingfeng  | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Contrib apps  |   Version:  1.0 
Resolution:|  Keywords:  sitemaps
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by Tarken):

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

Comment:

 I won't close this myself, as I have no official word in the development
 of Django... but this appears to be invalid.

 DOMAIN is not a setting which is currently set or used anywhere else in
 Django. Nor does it appear to really be necessary. Django can't account
 for every setting that you may add to your project.

-- 
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] #10910: Unicode dictionary keys cause TypeError when used as arguments to filter()

[Django]

#10910: Unicode dictionary keys cause TypeError when used as arguments to 
filter()
--+-
 Reporter:  mostrovsky|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I'm using dictionaries to pass arguments to a filter. If the keys of the
 dictionary are unicode, this causes a TypeError similar to the ones seen
 in previous tickets (see #10645, which fixed this problem from the admin
 side of things)

 {{{

 >>> filter_args = {u'date_created':'2009-01-01'}
 >>> MyClass.objects.filter(**filter_args)
 >>> TypeError: filter() keywords must be strings

 }}}

 Of course, casting the keys by using str() fixes the problem.

 This behavior can bee seen on trunk, revision 10630, with python2.5

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10909: Django Sitemaps Framework does not allow the use of the Domain Settings Site

[Django]

#10909: Django Sitemaps Framework does not allow the use of the Domain Settings
Site
--+-
 Reporter:  qingfeng  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  1.0   
 Keywords:  sitemaps  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Django Sitemaps Framework does not allow the use of the Domain Settings
 Site


 In settings.py add a variable DOMAIN

 {{{
 DOMAIN = 'www.example.com'
 }}}

 example:
 location of the place, do not rely on the domain name Site Settings
 {{{
 class KhufuSitemap(Sitemap):
 changefreq = "never"
 priority = 0.5

 def items(self):
 return [obj,obj,obj]

 def location(self,obj):
 return "/v/%s/" % obj["kid"]

 def lastmod(self, obj):
 return datetime.strptime(obj["savedate"],'%Y-%m-%d')

 }}}

-- 
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] #9120: Improve error reports for exceptions in models.loading.load_app

[Django]

#9120: Improve error reports for exceptions in models.loading.load_app
-+--
  Reporter:  hvendelbo   | Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Core framework  |   Version:  1.0  
  
Resolution:  |  Keywords:  
ImportError,load_app,Error:
 Stage:  Design decision needed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by lsaffre):

 hvendelbo, why do you say that "Outputting a stack trace is really too
 much information"?
 Here is a patch that helped me to solve the same problem (import error
 caused by my code,
 occuring during {{{translation.activate('en-us')}}} where import errors
 are captured).
 I don't see why outputting the stack trace is really too much information.

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

Re: [Django] #10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name

[Django]

#10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name
---+
  Reporter:  Richard Davies   |
 Owner:  nobody
Status:  closed| 
Milestone:  1.1   
 Component:  File uploads/storage  |   
Version:
Resolution:  worksforme|  
Keywords:
 Stage:  Unreviewed| 
Has_patch:  0 
Needs_docs:  0 |   
Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 See Karen's note: unicode path support only works if your filesystem does.

-- 
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] #10908: Information about proper way of user creation for testing

[Django]

#10908: Information about proper way of user creation for testing
+---
  Reporter:  gruszczy   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by timo):

 +1. I had this problem recently as well.  I think the issue is that using
 create() doesn't hash the password.  I had to use set_password() until I
 discovered create_user().

-- 
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] #10888: Inserting model with GeometryField as None crashes on Oracle

[Django]

#10888: Inserting model with GeometryField as None crashes on Oracle
-+--
  Reporter:  jtiai   | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:  oracle gis
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by jtiai):

 Quote from Anthony Tuininga on cx-oracle-users list:
 > This is expected behavior, unfortunately. Oracle requires a type to be
 > specified and if all you supply is None cx_Oracle has no choice but to
 > assume something. And CHAR seems the most likely to cause the least
 > difficulties. cx_Oracle currently has no way of binding in Oracle
 > object values like MDSYS.SDO_GEOMETRY.


 So this is now real problem since you cant have null geometries easily.

-- 
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] #10907: Adding google news sitemap support to django.contrib.sitemaps

[Django]

#10907: Adding google news sitemap support to django.contrib.sitemaps
---+
  Reporter:  lakinwecker   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by msimoens):

 * cc: msimoens (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] #10908: Information about proper way of user creation for testing

[Django]

#10908: Information about proper way of user creation for testing
+---
  Reporter:  gruszczy   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by ramiro):

 Replying to [ticket:10908 gruszczy]:
 > I have created user using User.objects.create and then tried
 Client().login and it constantly fails. The proper way was to user
 User.objects.create_user, but there was not a word in testing docs! There
 should be such information. Here is the link:
 
http://docs.djangoproject.com/en/dev/topics/testing/#django.test.client.Client.login

 Are you sure you are correctly using `create()`?
 
[http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/comment_tests/tests/__init__.py?rev=10122#L40
 This test] shows an user can be created without having to resort to use
 `create_user()` and the [http://docs.djangoproject.com/en/dev/topics/auth
 /#creating-users documentation says] it is ''"The most basic way"'' not
 that it is the proper or exclusive way to add an user.

-- 
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] #10907: Adding google news sitemap support to django.contrib.sitemaps

[Django]

#10907: Adding google news sitemap support to django.contrib.sitemaps
---+
  Reporter:  lakinwecker   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

Comment:

 It looks like you left a bit of hard-coded data on line 14 of
 django/contrib/sitemaps/templates/news_sitemap.xml

 {{{
 {% if url.keywords %}Business, Mergers,
 Acquisitionsnews:keywords>{% endif %}
 }}}

-- 
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] #10223: Admin has a bug for primary keys that contain slashes

[Django]

#10223: Admin has a bug for primary keys that contain slashes
---+
  Reporter:  HuCy  | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * needs_better_patch:  1 => 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] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
--+-
  Reporter:  fas  | Owner:  fas 

Status:  new  | Milestone:  

 Component:  ORM aggregation  |   Version:  SVN 

Resolution:   |  Keywords:  orm, aggregation, join, 
contenttypes, filter
 Stage:  Accepted | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by fas):

 Is this going in for 1.1? I think it should as it would otherwise leave a
 new feature with a quite serious 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] #10908: Information about proper way of user creation for testing

[Django]

#10908: Information about proper way of user creation for testing
+---
  Reporter:  gruszczy   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gruszczy):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Documentation
  * 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] #10908: Information about proper way of user creation for testing

[Django]

#10908: Information about proper way of user creation for testing
---+
 Reporter:  gruszczy   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I have created user using User.objects.create and then tried
 Client().login and it constantly fails. The proper way was to user
 User.objects.create_user, but there was not a word in testing docs! There
 should be such information. Here is the link:
 
http://docs.djangoproject.com/en/dev/topics/testing/#django.test.client.Client.login

-- 
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
-~--~~~~--~~--~--~---

[Changeset] r10630 - django/branches/releases/1.0.X/django/forms

[noreply]

Author: jacob
Date: 2009-04-23 09:18:11 -0500 (Thu, 23 Apr 2009)
New Revision: 10630

Modified:
   django/branches/releases/1.0.X/django/forms/models.py
Log:
[1.0.X] Fixed #10163: add an artificial ordering to querysets used by formsets, 
thus ensuring that POSTed data "lines up" correctly every time. Thanks to Karen 
Tracey for pointing in the right direction here.

This is a backport of [10625] from trunk, in a sense. In 1.1 I added a 
`QuerySet.ordered` property to deal with the logic of determining whether a 
queryset has ordering, but we can't add new features on a bugfix branch. So 
here in 1.0-land, the logic has to live in the formset. This smells, but it's 
better than having a bug.

Modified: django/branches/releases/1.0.X/django/forms/models.py
===
--- django/branches/releases/1.0.X/django/forms/models.py   2009-04-23 
14:18:02 UTC (rev 10629)
+++ django/branches/releases/1.0.X/django/forms/models.py   2009-04-23 
14:18:11 UTC (rev 10630)
@@ -388,6 +388,24 @@
 qs = self.queryset
 else:
 qs = self.model._default_manager.get_query_set()
+
+# If the queryset isn't already ordered we need to add an
+# artificial ordering here to make sure that all formsets
+# constructed from this queryset have the same form order.
+#
+# This logic is in the wrong place here on the 1.0.X branch.
+# In the 1.1 series this logic exists as the QuerySet.ordered
+# property, but since that's new in 1.1 here in 1.0 we just 
+# have to deal with this slightly smelly code here.
+if qs.query.extra_order_by or qs.query.order_by:
+ordered = True
+elif qs.query.default_ordering and qs.query.model._meta.ordering:
+ordered = True
+else:
+ordered = False
+if not ordered:
+qs = qs.order_by(qs.model._meta.pk.name)
+
 if self.max_num > 0:
 self._queryset = qs[:self.max_num]
 else:


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[Changeset] r10629 - django/branches/releases/1.0.X/django/contrib/admin/views

[noreply]

Author: jacob
Date: 2009-04-23 09:18:02 -0500 (Thu, 23 Apr 2009)
New Revision: 10629

Modified:
   django/branches/releases/1.0.X/django/contrib/admin/views/main.py
Log:
[1.0.X] Fixed a needless list() coercion in in ChangeList. Refs #10163. 
Backport of [10624] from trunk.

Modified: django/branches/releases/1.0.X/django/contrib/admin/views/main.py
===
--- django/branches/releases/1.0.X/django/contrib/admin/views/main.py   
2009-04-22 22:45:23 UTC (rev 10628)
+++ django/branches/releases/1.0.X/django/contrib/admin/views/main.py   
2009-04-23 14:18:02 UTC (rev 10629)
@@ -115,7 +115,7 @@
 
 # Get the list of objects to display on this page.
 if (self.show_all and can_show_all) or not multi_page:
-result_list = list(self.query_set)
+result_list = self.query_set._clone()
 else:
 try:
 result_list = paginator.page(self.page_num+1).object_list


--~--~-~--~~~---~--~~
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] #10907: Adding google news sitemap support to django.contrib.sitemaps

[Django]

#10907: Adding google news sitemap support to django.contrib.sitemaps
--+-
 Reporter:  lakinwecker   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Contrib apps  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=74288
 Google News Sitemaps] are very similar to normal sitemaps in that they
 build off of the sitemaps protocol.  They add a new namespace to the xml
 file, along with some added news-specific attributes to eatch url.

 This patch adds support for generation of these news sitemaps to the
 django.contrib.sitemaps application.

 There were no tests for this package - so I have not added any news tests.
 I have however, made an attempt to update the documentation for sitemaps.

-- 
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] #10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name

[Django]

#10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name
---+
  Reporter:  Richard Davies   |
 Owner:  nobody
Status:  new   | 
Milestone:  1.1   
 Component:  File uploads/storage  |   
Version:
Resolution:|  
Keywords:
 Stage:  Unreviewed| 
Has_patch:  0 
Needs_docs:  0 |   
Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 What is your LANG set to?  You are seeing a failure often seen under
 Apache due to an incorrect LANG setting:

 
http://code.djangoproject.com/wiki/django_apache_and_mod_wsgi#AdditionalTweaking

 I suspect you have LANG set to something like C, which results in the
 ascii codec being used for encoding unicode file paths passed into system
 calls. As the file path for that test can't be represented in ASCII, you
 get an error.  Setting LANG to something like 'en_US.UTF-8' will cause the
 utf8 codec to be used for encoding file paths to bytestrings, and the test
 will pass.

-- 
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] #10850: Impossible to stop a large file upload mid-stream

[Django]

#10850: Impossible to stop a large file upload mid-stream
---+
  Reporter:  legutierr | Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  SVN   
Resolution:|  Keywords:  upload, StopUpload
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Karen meant to link to #10902

-- 
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] #8898: `required` validation bypassed when using `DateTimeField` with `SplitDateTimeWidget`.

[Django]

#8898: `required` validation bypassed when using `DateTimeField` with
`SplitDateTimeWidget`.
-+--
  Reporter:  mrmachine   | Owner:  nobody   

Status:  new | Milestone:   

 Component:  Forms   |   Version:  SVN  

Resolution:  |  Keywords:  DateTimeField 
SplitDateTimeWidget
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 Also related: #9721.  That one wants to mix together the
 !SplitDateTimeWidget with a !DateTimeField in order to allow for an
 optional time component.  Perhaps that is why !DateTimeField was given
 some support for getting input from a !SplitDateTimeWidget in the first
 place?  If so I think a better approach could be to add support for that
 kind of thing to the !SplitDateTimeField/!SplitDateTimeWidget combo rather
 than trying to mix a split widget with a non-split 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] #9721: DateTimeField does not support all DEFAULT_DATETIME_INPUT_FORMATS when passed a list as input

[Django]

#9721: DateTimeField does not support all DEFAULT_DATETIME_INPUT_FORMATS when
passed a list as input
-+--
  Reporter:  uggedal | Owner:  nobody   

Status:  new | Milestone:   

 Component:  Forms   |   Version:  SVN  

Resolution:  |  Keywords:  DateTimeFIeld 
SplitDateTimeWidget
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 Also related: #8898.  In general it strikes me that using a
 !SplitDateTimeWidget with a !DateTimeField is a wrong approach.  We've got
 the !SplitDateTimeField to go with the !SplitDateTimeWidget.  If there is
 some use case that those two together don't support (half of it being
 optional) then I think that should be addressed by enhancing them, not
 trying to mix together a split widget with a non-split 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] #10889: ModelAdmin calls .log_deletion after deletion, causing invalid object_id

[Django]

#10889: ModelAdmin calls .log_deletion after deletion, causing invalid object_id
---+
  Reporter:  jdunck| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jdunck):

 ramiro,
   Alex and I discussed that-- unfortunately, I don't think it can be
 easily fixed, because .log_deletion is a public method of ModelAdmin,
 which may have been subclassed.  log_deletion takes the object being
 deleted as a parameter, not just the object PK, so the only way I can see
 reversing this would be some hackery like:

 {{{
 old_obj_pk = obj.pk
 obj.delete()
 new_obj_pk = obj.pk
 try:
obj.pk = old_obj_pk
self.log_deletion(...,obj,...)
 finally:
obj.pk = new_obj_pk
 }}}

 This strikes me as more than a little gross.

 Opinions?

-- 
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] #6533: Syndication Framework: Item titles and descriptions double-escaped

[Django]

#6533: Syndication Framework: Item titles and descriptions double-escaped
+---
  Reporter:  miracle2k  | Owner:  jacob
Status:  reopened   | Milestone:  1.0  
 Component:  RSS framework  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  1  |  
+---
Changes (by arty):

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

Comment:

 Actually Atom has feature to fight exactly this issue: title element can
 have attribute type="text|html|xhtml", which explicitly defines how much
 escaping was applied to title. So adding type="xhtml" to title and double
 escaping text in it should be the right and safe.

 http://www.atomenabled.org/developers/syndication/atom-format-
 spec.php#element.title
 http://www.atomenabled.org/developers/syndication/atom-format-
 spec.php#text.constructs
 http://intertwingly.net/blog/2006/07/14/Another-Month#c1152903120

-- 
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] #9206: Improve documentation on raw SQL queries

[Django]

#9206: Improve documentation on raw SQL queries
---+
  Reporter:  Richard Davies   |
 Owner:  nobody
Status:  new   | 
Milestone:  1.1   
 Component:  Documentation |   
Version:  SVN   
Resolution:|  
Keywords:
 Stage:  Accepted  | 
Has_patch:  1 
Needs_docs:  0 |   
Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Richard Davies ):

  * version:  1.0 => SVN
  * milestone:  => 1.1

Comment:

 Here's an update incorporating Malcolm's comments. Note that I de-
 duplicate descriptions of raw SQL in doc/topics/db/models.txt and
 doc/topics/db/sql.txt. These are currently marginally different. I'm
 assuming that sql.txt is the current master version and that the other one
 is outdated, but the committer should double-check 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
-~--~~~~--~~--~--~---

Re: [Django] #10850: Impossible to stop a large file upload mid-stream

[Django]

#10850: Impossible to stop a large file upload mid-stream
---+
  Reporter:  legutierr | Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  SVN   
Resolution:|  Keywords:  upload, StopUpload
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 #10850 was a dupe with a sample upload handler.

-- 
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] #10902: FileUploadHandler not working, requests are always buffered.

[Django]

#10902: FileUploadHandler not working, requests are always buffered.
---+
  Reporter:  tkopc...@gmail.com| Owner:  nobody 
 
Status:  closed| Milestone:  1.0.3  
 
 Component:  File uploads/storage  |   Version:  1.0
 
Resolution:  duplicate |  Keywords:  fileuploadhandler 
buffering requests
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 Replying to [comment:1 grahamd]:
 > Is this the same issue as #10850?
 Yes, thanks for pointing that out.  I knew I'd seen discussion of this
 lately but I thought it was on a mailing list.

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

Re: [Django] #10889: ModelAdmin calls .log_deletion after deletion, causing invalid object_id

[Django]

#10889: ModelAdmin calls .log_deletion after deletion, causing invalid object_id
---+
  Reporter:  jdunck| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Only (minor?) problem with moving the log_deletion() call to above the
 actual deletion is this might leave the log event with inaccurate
 information (reporting a successful action) if the obj.delete() fails for
 some reason and throws an exception.

-- 
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] #10904: Minor Error with Relative vs. Absolute URL

[Django]

#10904: Minor Error with Relative vs. Absolute URL
+---
  Reporter:  sharan666  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

Comment:

 Looks like this is on docs/ref/templates/builtins.txt

-- 
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] #10888: Inserting model with GeometryField as None crashes on Oracle

[Django]

#10888: Inserting model with GeometryField as None crashes on Oracle
-+--
  Reporter:  jtiai   | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:  oracle gis
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jtiai):

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

Comment:

 Further investigation indicates that this is more likely a Bug in
 cx_Oracle than Geodjango framework.

-- 
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] #10906: Aggregation support absent on postgres < 8.2

[Django]

#10906: Aggregation support absent on postgres < 8.2
--+-
 Reporter:  Richard Davies   |  Status:  
new
Milestone:  1.1   |   Component:  
ORM aggregation
  Version:  SVN   |Keywords:
 
Stage:  Unreviewed|   Has_patch:  0 
 
--+-
 Running the test suite on a clean check out of r10628, with PostgreSQL 8.1
 and psycopg2, I get numerous errors from the
 regressiontests/aggregation_regress/, including:

 {{{
 ProgrammingError: function stddev_pop(integer) does not exist
 ProgrammingError: function stddev_samp(integer) does not exist
 ProgrammingError: function var_pop(integer) does not exist
 ProgrammingError: function var_samp(integer) does not exist
 }}}

 I believe that these aggregates were first implemented in PostgreSQL 8.2,
 so either the aggregation code itself or at least the test cases should be
 conditional on that version.

 See [10142] for an existing error message on PostgreSQL 8.2 to 8.2.4,
 which could perhaps be extended downwards?

-- 
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] #10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name

[Django]

#10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name
---+
  Reporter:  Richard Davies   |
 Owner:  nobody
Status:  new   | 
Milestone:  1.1   
 Component:  File uploads/storage  |   
Version:
Resolution:|  
Keywords:
 Stage:  Unreviewed| 
Has_patch:  0 
Needs_docs:  0 |   
Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Richard Davies ):

  * needs_better_patch:  => 0
  * version:  1.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] #8754: PYTHONPATH not passed through to regressiontests/admin_scripts/AdminScriptTestCase.run_test()

[Django]

#8754: PYTHONPATH not passed through to
regressiontests/admin_scripts/AdminScriptTestCase.run_test()
---+
  Reporter:  Richard Davies   |
 Owner:  nobody
Status:  new   | 
Milestone:  1.1   
 Component:  Testing framework |   
Version:  SVN   
Resolution:|  
Keywords:
 Stage:  Accepted  | 
Has_patch:  1 
Needs_docs:  0 |   
Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Richard Davies ):

  * milestone:  => 1.1

Comment:

 Tested this morning on r10628. Bug still exists, and patch still works for
 me. Let's get this into 1.1.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name

[Django]

#10905: UnicodeEncodeError from FileUploadTests.test_unicode_file_name
--+-
 Reporter:  Richard Davies   |   Owner:  
nobody
   Status:  new   |   Milestone:  
1.1   
Component:  File uploads/storage  | Version:  
1.0   
 Keywords:|   Stage:  
Unreviewed
Has_patch:  0 |  
--+-
 Running the test suite on a clean check out of r10628, I get:

 {{{
 ==
 ERROR: test_unicode_file_name
 (regressiontests.file_uploads.tests.FileUploadTests)
 --
 Traceback (most recent call last):
   File "/home/elastic-
 www/test/trunk/tests/regressiontests/file_uploads/tests.py", line 67, in
 test_unicode_file_name
 response = self.client.post('/file_uploads/unicode_name/', post_data)
   File "/home/elastic-www/test/trunk/django/test/client.py", line 313, in
 post
 response = self.request(**r)
   File "/home/elastic-www/test/trunk/django/core/handlers/base.py", line
 92, in get_response
 response = callback(request, *callback_args, **callback_kwargs)
   File "/home/elastic-
 www/test/trunk/tests/regressiontests/file_uploads/views.py", line 64, in
 file_upload_unicode_name
 obj = FileModel.objects.create(testfile=uni_named_file)
   File "/home/elastic-www/test/trunk/django/db/models/manager.py", line
 126, in create
 return self.get_query_set().create(**kwargs)
   File "/home/elastic-www/test/trunk/django/db/models/query.py", line 284,
 in create
 obj.save(force_insert=True)
   File "/home/elastic-www/test/trunk/django/db/models/base.py", line 407,
 in save
 self.save_base(force_insert=force_insert, force_update=force_update)
   File "/home/elastic-www/test/trunk/django/db/models/base.py", line 471,
 in save_base
 values = [(f, f.get_db_prep_save(raw and getattr(self, f.attname) or
 f.pre_save(self, True))) for f in meta.local_fields if not isinstance(f,
 AutoField)]
   File "/home/elastic-www/test/trunk/django/db/models/fields/files.py",
 line 191, in pre_save
 file.save(file.name, file, save=False)
   File "/home/elastic-www/test/trunk/django/db/models/fields/files.py",
 line 83, in save
 self._name = self.storage.save(name, content)
   File "/home/elastic-www/test/trunk/django/core/files/storage.py", line
 46, in save
 name = self.get_available_name(name)
   File "/home/elastic-www/test/trunk/django/core/files/storage.py", line
 68, in get_available_name
 while self.exists(name):
   File "/home/elastic-www/test/trunk/django/core/files/storage.py", line
 198, in exists
 return os.path.exists(self.path(name))
   File "/lib/python2.5/posixpath.py", line 171, in exists
 st = os.stat(path)
 UnicodeEncodeError: 'ascii' codec can't encode characters in position
 43-44: ordinal not in range(128)
 }}}

 My command line to run the tests was:

 {{{
 $ cat settings.py
 DATABASE_ENGINE='sqlite3'
 $ ./runtests.py --settings=settings file_uploads
 }}}

-- 
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] #9721: DateTimeField does not support all DEFAULT_DATETIME_INPUT_FORMATS when passed a list as input

[Django]

#9721: DateTimeField does not support all DEFAULT_DATETIME_INPUT_FORMATS when
passed a list as input
-+--
  Reporter:  uggedal | Owner:  nobody   

Status:  new | Milestone:   

 Component:  Forms   |   Version:  SVN  

Resolution:  |  Keywords:  DateTimeFIeld 
SplitDateTimeWidget
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Comment (by antondubkov):

 I've encountered a problem with using DateTimeField(required=False) and
 SplitDateTimeWidget (or AdminSplitDateTime) - these widgets don't let you
 leave the field empty. This happens because in this case the value is
 [u'', u''], but EMPTY_VALUES = (None, ''). So either EMPTY_VALUES should
 be extended, or value should be converted to string (if isinstance(value,
 list)) before checking against EMPTY_VALUES.

-- 
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] #10904: Minor Error with Relative vs. Absolute URL

[Django]

#10904: Minor Error with Relative vs. Absolute URL
---+
 Reporter:  sharan666  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Returns an absolute URL (i.e., a URL without the domain name

 should read

 Returns an relative URL (i.e., a URL without the domain name

-- 
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] #10894: django.test.client.post does not throw exception when selected foreign key does not exists

[Django]

#10894: django.test.client.post does not throw exception when selected foreign 
key
does not exists
+---
  Reporter:  Carlos   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by carlosble):

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

Comment:

 Good point mktracey. I thought this use case could not be performed
 through the UI as the browser does not let you pick a foreign key which is
 not in the rendered dropdow, but if there are several users accesing the
 site and one deletes the foreign key selected by the other, then you get
 same case which solution would be a redirect as you point. I am getting
 status_code 200 but I guess it is up to me to validate and get a 30x code.
 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
-~--~~~~--~~--~--~---