Re: [Django] #11931: ForeignKey documentation mentions non-existent method

[Django]

#11931: ForeignKey documentation mentions non-existent method
+---
  Reporter:  danielr| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by ubernostrum):

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

Comment:

 The actual criterion is anything that's a `Q` object or has an
 `add_to_query()` method.

-- 
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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
---+
  Reporter:  danbrwn   | Owner:  mitsuhiko  
   
Status:  new   | Milestone:  1.2
   
 Component:  Database layer (models, ORM)  |   Version:  1.1
   
Resolution:|  Keywords:  
foreign,key,quoted
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: subs...@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
-~--~~~~--~~--~--~---

[Django] #11931: ForeignKey documentation mentions non-existent method

[Django]

#11931: ForeignKey documentation mentions non-existent method
---+
 Reporter:  danielr|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The documentation for ForeignKey fields
 (http://docs.djangoproject.com/en/dev/ref/models/fields/#arguments)
 mentions Q objects as having a get_sql() method. They don't have such a
 method - possibly they did before queryset-refactor, but not now. Patch
 attached removes this, and links the reference to Q objects to the
 description on the Making queries page (because there is no reference page
 for Q).

-- 
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] r11589 - django/branches/releases/1.1.X/docs/internals

[noreply]

Author: ubernostrum
Date: 2009-09-22 16:21:45 -0500 (Tue, 22 Sep 2009)
New Revision: 11589

Modified:
   django/branches/releases/1.1.X/docs/internals/svn.txt
Log:
[1.1.X] The 1.1.X branch has been created, so that needs to be past tense. 
Backport of [11588] from trunk.

Modified: django/branches/releases/1.1.X/docs/internals/svn.txt
===
--- django/branches/releases/1.1.X/docs/internals/svn.txt   2009-09-22 
21:20:51 UTC (rev 11588)
+++ django/branches/releases/1.1.X/docs/internals/svn.txt   2009-09-22 
21:21:45 UTC (rev 11589)
@@ -199,7 +199,7 @@
 release. For example, shortly after the release of Django 1.0, the
 branch ``django/branches/releases/1.0.X`` was created to receive bug
 fixes, and shortly after the release of Django 1.1 the branch
-``django/branches/releases/1.1.X`` will be created.
+``django/branches/releases/1.1.X`` was created.
 
 Prior to the Django 1.0 release, these branches were maintaind within
 the top-level ``django/branches`` directory, and so the following


--~--~-~--~~~---~--~~
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] r11590 - django/trunk/django/utils

[noreply]

Author: lukeplant
Date: 2009-09-22 16:21:51 -0500 (Tue, 22 Sep 2009)
New Revision: 11590

Modified:
   django/trunk/django/utils/decorators.py
Log:
Fixed typo in docstring for decorator_from_middleware_with_args.

Thanks for the report, kmike



Modified: django/trunk/django/utils/decorators.py
===
--- django/trunk/django/utils/decorators.py 2009-09-22 21:21:45 UTC (rev 
11589)
+++ django/trunk/django/utils/decorators.py 2009-09-22 21:21:51 UTC (rev 
11590)
@@ -41,7 +41,7 @@
 that accepts the arguments to be passed to the middleware_class.
 Use like::
 
- cache_page = decorator_from_middleware(CacheMiddleware)
+ cache_page = decorator_from_middleware_with_args(CacheMiddleware)
  # ...
 
  @cache_page(3600)


--~--~-~--~~~---~--~~
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] r11588 - django/trunk/docs/internals

[noreply]

Author: ubernostrum
Date: 2009-09-22 16:20:51 -0500 (Tue, 22 Sep 2009)
New Revision: 11588

Modified:
   django/trunk/docs/internals/svn.txt
Log:
The 1.1.X branch has been created, so that needs to be past tense.

Modified: django/trunk/docs/internals/svn.txt
===
--- django/trunk/docs/internals/svn.txt 2009-09-21 22:34:45 UTC (rev 11587)
+++ django/trunk/docs/internals/svn.txt 2009-09-22 21:20:51 UTC (rev 11588)
@@ -199,7 +199,7 @@
 release. For example, shortly after the release of Django 1.0, the
 branch ``django/branches/releases/1.0.X`` was created to receive bug
 fixes, and shortly after the release of Django 1.1 the branch
-``django/branches/releases/1.1.X`` will be created.
+``django/branches/releases/1.1.X`` was created.
 
 Prior to the Django 1.0 release, these branches were maintaind within
 the top-level ``django/branches`` directory, and so the following


--~--~-~--~~~---~--~~
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] #11741: PostgreSQL/PostGIS backend table quoting bug in nested queries

[Django]

#11741: PostgreSQL/PostGIS backend table quoting bug in nested queries
+---
  Reporter:  n...@urbanmapping.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  GIS|   Version:  1.1   
Resolution: |  Keywords:  PostGIS Postgresql
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by jaklaas...@gmail.com):

 I think the attached diffs will fix the problem.  GeoWhereNode can pass
 the quote function through to get_geo_where_clause.

-- 
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] #11925: Extension to ModelForm

[Django]

#11925: Extension to ModelForm
+---
  Reporter:  andrew.mcmu...@ifi.uio.no  | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Forms  |   Version:  SVN
Resolution: |  Keywords:  model forms
 Stage:  Unreviewed | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by orutherfurd):

 * cc: orutherf...@gmail.com (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
-~--~~~~--~~--~--~---

Re: [Django] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  assigned | Milestone:  1.2 
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:   |  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by schmilblick):

 The patch solved my problems as well, but like twold wrote; it's really
 awkward patching stuff in prod.
 Status? 1.2?

-- 
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] #11126: Admin model.ManyToManyField doesn't support legacy db tables and custom model.ForeignKey fields

[Django]

#11126: Admin model.ManyToManyField doesn't support  legacy db tables and custom
model.ForeignKey fields
+---
  Reporter:  mwil...@methodstudios.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  django.contrib.admin   |   Version:  SVN   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 http://undefined.org.ua/blog/2008/02/29/manytomanywithcustomfield/?lang=en

 Here's a great link illustrating one way that the manytomany field should
 work without having to override it.

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

Re: [Django] #11126: Admin model.ManyToManyField doesn't support legacy db tables and custom model.ForeignKey fields

[Django]

#11126: Admin model.ManyToManyField doesn't support  legacy db tables and custom
model.ForeignKey fields
+---
  Reporter:  mwil...@methodstudios.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  django.contrib.admin   |   Version:  SVN   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 Although the above is not a true bug, it is something that's difficult to
 work with and non-intuitive. So consider this a vote for a new feature
 request. The root problem is not configuration of the admin interface, it
 is that if you use the "through" parameter it assumes you have additional
 data that needs to be added. This is rarely the case in a legacy database
 situation.

 There are a couple possible solutions:
 1. Have the ORM inspect the through model and find the correct foreign key
 fields to make normal manytomany functionality work (like add() or admin
 forms).
 2. Allow two more optional parameters (or a tuple or something), to allow
 manually naming the foreign key fields.

 This would allow a legacy m2m behave like a native one when there's no
 additional data (which is most of the time). I work in a corporate setting
 where getting django to connect to "legacy" data (any database not created
 by django) is indispensable, and this will only become more common when
 the multi-db branch lands in the trunk.

-- 
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] #11930: Django docs styles confuse H3 & H4

[Django]

#11930: Django docs styles confuse H3 & H4
-+--
 Reporter:  da...@whatcould.com  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The Django docs are confusing because H3 is considerably less prominent
 than H4.

 For example, check out http://docs.djangoproject.com/en/dev/howto/custom-
 template-tags/, and try to find where it starts talking about writing your
 own tags (not your own filters).

 The H3 is 15px but looks almost the same size as the H4, which is all-caps
 and black. I think the solution is making h3 a bit stronger, with more
 margin-top, and the H4 not #000.

 Y'all might not notice, since you're already clued in to look for the
 green. But even after a week navigating these, I still am confused looking
 through them.

-- 
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] #11929: manage.py dumpdata outputs YAML in unhelpful order

[Django]

#11929: manage.py dumpdata outputs YAML in unhelpful order
---+
 Reporter:  sampablokuper  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Serialization  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The [http://docs.djangoproject.com/en/dev/howto/initial-data/ docs]
 suggest providing initial YAML data in the following format:

 {{{
 - model: myapp.person
   pk: 1
   fields:
 first_name: John
 last_name: Lennon
 }}}

 but the manage.py dumpdata outputs YAML in the following form:

 {{{
 -   fields: {first_name: John, last_name: Lennon}
 model: myapp.person
 pk: 1
 }}}

 The fact that this is flow rather than block style YAML is the subject of
 [http://code.djangoproject.com/ticket/11927 #11927], but there's another
 problem, which is that rather than putting the model and PK first (which
 is most human-readable), dumpdata outputs the fields first.

-- 
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] #11928: EmailMessage.to accepts tuple or list, but EmailMessage.recipients() fails if it's a tuple

[Django]

#11928: EmailMessage.to accepts tuple or list, but EmailMessage.recipients() 
fails
if it's a tuple
---+
  Reporter:  bendavis78| Owner:  bendavis78   
Status:  assigned  | Milestone:   
 Component:  django.core.mail  |   Version:  SVN  
Resolution:|  Keywords:  mail to tuple
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by bendavis78):

  * owner:  nobody => bendavis78
  * needs_better_patch:  => 0
  * status:  new => assigned
  * 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] #11928: EmailMessage.to accepts tuple or list, but EmailMessage.recipients() fails if it's a tuple

[Django]

#11928: EmailMessage.to accepts tuple or list, but EmailMessage.recipients() 
fails
if it's a tuple
--+-
 Reporter:  bendavis78|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.core.mail  | Version:  SVN   
 Keywords:  mail to tuple |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Basically, if you set "to" to a tuple, the recipients() method fails
 because it's concatenating self.to + self.bcc,  and bcc by default is [].
 So if self.to is a tuple, you get an exception. The simple fix is:
 {{{
 Index: django/core/mail.py
 ===
 --- django/core/mail.py (revision 11587)
 +++ django/core/mail.py (working copy)
 @@ -255,7 +255,7 @@
  Returns a list of all recipients of the email (includes direct
  addressees as well as Bcc entries).
  """
 -return self.to + self.bcc
 +return list(self.to) + list(self.bcc)

  def send(self, fail_silently=False):
  """Sends the email message."""
 }}}

-- 
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] #11927: Allow manage.py dumpdata to dump YAML in block style

[Django]

#11927: Allow manage.py dumpdata to dump YAML in block style
+---
  Reporter:  sampablokuper  | Owner:  nobody
Status:  new| Milestone:
 Component:  Serialization  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by sampablokuper):

 * cc: sam.ku...@uclmail.net (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Added to CC 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
-~--~~~~--~~--~--~---

[Django] #11927: Allow manage.py dumpdata to dump YAML in block style

[Django]

#11927: Allow manage.py dumpdata to dump YAML in block style
---+
 Reporter:  sampablokuper  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Serialization  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Using

 {{{
 python manage.py dumpdata --format=yaml
 }}}

 produces output in
 
[http://pyyaml.org/wiki/PyYAMLDocumentation#Dictionarieswithoutnestedcollectionsarenotdumpedcorrectly
 flow style]. That's OK for automated processing, but it isn't anything
 like as human-readable as block style YAML. For people who, like me, need
 to edit the fixtures manually, it would be very useful to be able to do
 something like:

 {{{
 python manage.py dumpdata --format=yaml --flowstyle=false
 }}}

-- 
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] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner: 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: dnordb...@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] #11921: UnicodeEncodeError when using redirect_to with non-ascii keywords

[Django]

#11921: UnicodeEncodeError when using redirect_to with non-ascii keywords
+---
  Reporter:  IanLewis   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 Dupe of #11522.  I changed the summary there to remove the overly specific
 problem description; the discussion already made it clear the root of the
 problem is the location header is not consistently being url-encoded
 before being converted to ASCII.

-- 
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] #11522: UnicodeEncodeError on redirect to non-ASCII Location

[Django]

#11522: UnicodeEncodeError on redirect to non-ASCII Location
+---
  Reporter:  semenov| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by kmtracey):

 Closing #11921 as a dupe. Removed 'relative' from the summary since that
 was overly specific. Also, put non-ASCII in the summary since the problem
 is not use of Unicode but rather the presence of non-ASCII characters.  A
 Unicode string with all ASCII chars works fine.

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

Re: [Django] #11522: UnicodeEncodeError on redirect to non-ASCII Location

[Django]

#11522: UnicodeEncodeError on redirect to non-ASCII Location
+---
  Reporter:  semenov| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by kmtracey):

  * summary:  Crash on redirect to a relative URL if request.path is
  unicode => UnicodeEncodeError on redirect to
  non-ASCII Location

-- 
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] #11058: list_display_links doesn't allow callables not defined in the model

[Django]

#11058: list_display_links doesn't allow callables not defined in the model
---+
  Reporter:  dvine | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by sehmasch...@gmail.com):

 getting the same error here. it should at least be mentioned in the docs
 that list_display_links is different from list_display when it comes to
 callables and attributes.

-- 
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] #11923: Suspected typo in django/db/models/sql/query.py

[Django]

#11923: Suspected typo in django/db/models/sql/query.py
---+
  Reporter:  wogan | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Duplicate of #11764.

-- 
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] #11522: Crash on redirect to a relative URL if request.path is unicode

[Django]

#11522: Crash on redirect to a relative URL if request.path is unicode
+---
  Reporter:  semenov| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by semenov):

 IanLewis, you are mistaken. Unicode is a ''character set'', not an
 ''encoding''. That doesn't make sense to ''encode urls in ... Unicode''.
 URLs can be encoded in UTF8, CP1251 or any other encoding which are all
 mappings from a character set (Unicode) to particular byte strings.
 (Getting into details, URLs are actually encoded '''twice''' -- first from
 Unicode to byte strings, then from byte strings to lower-ASCII strings
 using the %XX notation).

 This ticket title mentions Unicode URLs and I consider that to be
 perfectly fine.

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

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

[Django]

#373: Add support for multiple-column primary keys
---+
  Reporter:  jacob | Owner:  dcramer 
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  
Resolution:|  Keywords:  database
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: st...@telcotec.se (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] #11926: URL regular expressions in wrong order

[Django]

#11926: URL regular expressions in wrong order
+---
  Reporter:  ginzor | Owner:  nobody  
Status:  closed | Milestone:  
 Component:  Documentation  |   Version:  1.1 
Resolution:  invalid|  Keywords:  tutorial
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

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

Comment:

 It does not matter what order they are in, since the '$' at the end
 matches the end of the string, so there is no need for 'fall through' -
 "polls/123/", for example, will match only the second pattern.

-- 
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] #11926: URL regular expressions in wrong order

[Django]

#11926: URL regular expressions in wrong order
---+
 Reporter:  ginzor |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords:  tutorial   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Either I have missed something completely or the following regular
 expressions are out of order. At least if I turn them around so the more
 specific turns up at the top the "fall through" and thereby the logic
 works properly for me.

 [http://docs.djangoproject.com/en/dev/intro/tutorial03/] several places

 {{{
 urlpatterns = patterns('',
 (r'^polls/$', 'mysite.polls.views.index'),
 (r'^polls/(?P\d+)/$', 'mysite.polls.views.detail'),
 (r'^polls/(?P\d+)/results/$', 'mysite.polls.views.results'),
 (r'^polls/(?P\d+)/vote/$', 'mysite.polls.views.vote'),
 )
 }}}

-- 
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] #11925: Extension to ModelForm

[Django]

#11925: Extension to ModelForm
---+
 Reporter:  andrew.mcmu...@ifi.uio.no  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords:  model forms|   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Currently when you want to alter the way a model field is represented as a
 form field, there is an all or nothing approach.  To change any of the
 form field parameters you have to specify them all, duplicating
 information from the model.  Here is an extension to ModelForm that allows
 selective parameter overriding.  An example of use:

 {{{
 class MyModel (models.Model):
 a = models.CharField(max_length=40)

 class MyForm (forms.ModelForm):
 class Meta:
 model = MyModel
 fields = ('a',)
 params = { 'a': { 'widget': forms.TextInput(attrs={'size':40}),
  'help_text': "This form field has the
 right size" } }
 }}}

 Seeing that the default method to generate a form field from a model field
 accepts a form_class keyword argument, you can use this to alter the field
 class used, without altering any of the parameters passed to initialise
 it.

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

[Django] #11924: Email headers always use the default encoding

[Django]

#11924: Email headers always use the default encoding
---+
 Reporter:  IanLewis   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When sending an email, the EmailMessage uses either the messages encoding
 property or if that isn't available it uses the DEFAULT_ENCODING setting.
 This behavior should apply to email headers as well. Currently even if a
 EmailMessage object's encoding property is set the DEFAULT_ENCODING is
 used to encode email headers.

 This means that you cannot send emails with headers encoded in any
 encoding other than the DEFAULT_ENCODING which is required for some mobile
 devices (particularly Japanese mobiles) and email readers.

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