Re: [Django] #13026: Problem with selecting related object from popup window, opened by lens icon in dynamic created inline row

[Django]

#13026: Problem with selecting related object from popup window, opened by lens
icon in dynamic created inline row
---+
  Reporter:  ramusus   | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted
  * milestone:  => 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-upda...@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] #13025: Test runner should print failed test path in format that is accepted by `manage.py test ...`

[Django]

#13025: Test runner should print failed test path in format that is accepted by
`manage.py test ...`
+---
  Reporter:  zimnyx | Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I'm going to close this wontfix - I can see what you're driving at, but
 there is a legitimate use for having the full class there - so you can
 actually find the test definition. This is also helpful if the test class
 names are ambiguous.

 Composing the actual test name isn't that hard once you have the full
 class name, so I'd rather stick to the fully qualified 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-upda...@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] #13005: We need a way to allow for request/user specific default values in the admin fields

[Django]

#13005: We need a way to allow for request/user specific default values in the
admin fields
---+
  Reporter:  hejsan| Owner:  nobody  
Status:  closed| Milestone:  
 Component:  django.contrib.admin  |   Version:  1.2-beta
Resolution:  wontfix   |  Keywords:  
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm going to close this wontfix; it's a bit of an edge case, and one you
 can already hit by overriding get_form() and returning a form class
 definition whose default values are programmaticaly derived

-- 
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-upda...@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] #13004: The new get_readonly_fields() method of the ModelAdmin breaks with many to many fields

[Django]

#13004: The new get_readonly_fields() method of the ModelAdmin breaks with many 
to
many fields
---+
  Reporter:  hejsan| Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  django.contrib.admin  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted
  * component:  Contrib apps => django.contrib.admin
  * milestone:  => 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-upda...@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] #13002: InlineModelAdmin 'form' option defaults to ModelForm, not BaseModelForm

[Django]

#13002: InlineModelAdmin 'form' option defaults to ModelForm, not BaseModelForm
-+--
  Reporter:  st...@typograaf.be  | Owner:  nobody
Status:  new | Milestone:
 Component:  Documentation   |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #12883: Adding values in a m2m field breaks (_state.db is None instead of "default")

[Django]

#12883: Adding values in a m2m field breaks (_state.db is None instead of
"default")
---+
  Reporter:  IonelMaries   | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I believe this is actually a duplicate of #13003. The issue is the
 select_related call not populating the _state.db of the related user
 object, which then causes the m2m assignment to fail.

-- 
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-upda...@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] #12972: flatpages chokes if the url doesn't begin and end with a slash (but doesn't validate for it)

[Django]

#12972: flatpages chokes if the url doesn't begin and end with a slash (but 
doesn't
validate for it)
---+
  Reporter:  jabapyth  | Owner:  jabapyth  
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:  flatpages, validation, 404
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jabapyth):

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

Comment:

 I looked around and there didn't seem to be any docs/readme on *how* to
 add tests to django (other than the basic ''this is a unittest'') -- I
 mean conventions, organization and the like. so bear with me.
 I created a new directory in /tests/regressiontests (I figured that was
 the right place for it...like I said, there didn't seem to be any
 intuitive difference between regressiontests and modeltests), called
 "flatpage_tests", and I put in some URL validation tests. is there
 anything I should change?

 btw. thanks so much for your guidance and council; as you can probably
 tell I'm fairly new at this. much appreciated.

-- 
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-upda...@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] #12883: Adding values in a m2m field breaks (_state.db is None instead of "default")

[Django]

#12883: Adding values in a m2m field breaks (_state.db is None instead of
"default")
---+
  Reporter:  IonelMaries   | Owner:  nobody
Status:  reopened  | Milestone:  1.2   
 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 ext):

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

Comment:

 I'm reopening, because, I've got the same problem.

 Code causing the problem is:

 {{{
 (...)
 project = form.save()
 admin_profiles =
 Member.objects.select_related().filter(group__name='Admin')
 for admin_profile in admin_profiles:
 project.users.add(admin_profile.user)
 }}}

 It is just adding users to a project.users which is m2m to auth.User.
 Error report is:
 {{{
 Traceback (most recent call last):
  File "/var/www/django/someapp/parts/django/django/core/handlers/
 base.py", line 101, in get_response
response = callback(request, *callback_args, **callback_kwargs)
  File "/var/www/django/someapp/webshare/utils.py", line 21, in wrapper
context = view_func(*args, **kwargs)
  File "/var/www/django/someapp/webshare/apps/projects/views.py", line
 100, in add_project
project.users.add(admin_profile.user)
  File "/var/www/django/someapp/parts/django/django/db/models/fields/
 related.py", line 465, in add
self._add_items(self.source_field_name, self.target_field_name,
 *objs)
  File "/var/www/django/someapp/parts/django/django/db/models/fields/
 related.py", line 525, in _add_items
(obj, self.instance._state.db, obj._state.db))
 ValueError: Cannot add "": instance is on database
 "default", value is is on database "None"
 }}}

 It is actually very strange. After I had used pdb and went through the
 code slowly there were no error! However during normal execution there
 is still a problem.

 I found that something goes wrong inside
 allow_relation method in django.db.utils. Last line of this function
 is:
 {{{
 return obj1._state.db == obj2._state.db
 }}}

 But when I print these variables i get:

 without pdb:

  * obj1._state.db:  None
  * obj2._state.db:  default

 with pdb (I mean step by step execution):
  * obj1._state.db:  default
  * obj2._state.db:  default

 Also see discussion here: http://groups.google.pl/group/django-
 users/browse_thread/thread/a81d6618fce29436?pli=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-upda...@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] #13033: MySQL full text search in admin

[Django]

#13033: MySQL full text search in admin
---+
  Reporter:  simon29   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by simon29):

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

Comment:

 To clarify, this was already half implemented. This finishes the job. So
 isn't really a new feature, just a fix :-)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13033: MySQL full text search in admin

[Django]

#13033: MySQL full text search in admin
--+-
 Reporter:  simon29   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Full text search hasn't been implemented properly in admin. The query is
 being word split and OR'd like regular fields.

 Attached patch fixes this, allowing you to type in any mysql boolean
 search.

 Simply prefix your admin search_fields with @ to use, eg ('@myfield', ).

 Be sure to include ALL the fields you have included in your index, else
 mysql might not use the full text index and instead default back to
 running a standard LIKE query.

 BTW, I can't recall the various search_field operators mentioned in docs?

-- 
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-upda...@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] #10937: Recommendation of mod_wsgi is incompatible with apache-authentication technique described in docs

[Django]

#10937: Recommendation of mod_wsgi is incompatible with apache-authentication
technique described in docs
+---
  Reporter:  d...@fritzing.org  | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  1.0
Resolution: |  Keywords:  mod_python mod_wsgi
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by davidfischer):

 There is some crossover here between this ticket and #10809. I think the
 fix for that ticket should cover this ticket as well.

-- 
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-upda...@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] #13006: Add order_by with sql LOWER() support

[Django]

#13006: Add order_by with sql LOWER() support
---+
  Reporter:  Raydiation| Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  
sql,order,lower
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Replying to [comment:2 Raydiation]:
 > Imho its about to write as little code as it needs

 Brevity is a nice side effect when possible, but clarity and flexibility
 is the real goal we are aiming at.

 !__lower suffers from several problems:
  * The literal python syntax you are proposing isn't actually valid python
 - you would need to pass the artists!__lower as a string.
  * Ignoring the syntax problem, it's inconsistent with current usage of
 the double underscore. Current usage is to define a comparison operator,
 not to define a transformation.
  * It's not easy for users to define their own operators.

 As another possible approach, I'd be much more likely to support:
 {{{
 result = MusicCollection.objects.all().order_by(LowerCase('artist__name'),
 LowerCase('songs__name'), LowerCase('genre__name'))
 }}}

 This is will ultimately require the same internal code, but avoids the
 need to explicitly name the annotations.

-- 
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-upda...@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] #13006: Add order_by with sql LOWER() support

[Django]

#13006: Add order_by with sql LOWER() support
---+
  Reporter:  Raydiation| Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  
sql,order,lower
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Hm, thats about the same as the method with extra.
 Imagine youd have to order 4 columns:

 {{{
 result = MusicCollection.objects.all().order_by(artists__lower,
 songs__lower, genre__lower, album__lower)
 }}}

 vs.

 {{{
 result =
 MusicCollection.objects.annotate(lcartist=LowerCase('artist__name'),
 lcsongs=LowerCase('songs__name'), lcgenre=LowerCase('genre__name'),
 lcalbum=LowerCase('artist__album')).order_by(lcartist, lcsongs, lcgenre,
 lcalbum)
 }}}

 vs.

 {{{
 result = MusicCollection.objects.all().extra(select={'lcartist':
 'lower(artist)', 'lcsongs': 'lower(song)', 'lcgenre': 'lower(genre)',
 'lalbum': 'lower(album)'}).order_by('lcartist', "lcsongs", "lcgenre",
 "lcalbum")
 }}}

 You see, annotate can take a wide spectrum of stuff, but it doesnt
 specifically tackle this common issue. Imho its about to write as little
 code as it needs, and the annotate version is even more to write than the
 extra version. I wouldnt call this an improvement.

-- 
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-upda...@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] #13014: Document using LANGUAGE_CODE with the cache template tag

[Django]

#13014: Document using LANGUAGE_CODE with the cache template tag
+---
  Reporter:  yml| Owner: 
Status:  new| Milestone:  1.2
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * has_patch:  1 => 0

Comment:

 The patch doesn't address the decision made to just document this
 behavior, Mr Anonymous.

-- 
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-upda...@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] #13032: USE_THOUSAND_SEPARATOR breaks forms by formatting primary key values, causing error on save

[Django]

#13032: USE_THOUSAND_SEPARATOR breaks forms by formatting primary key values,
causing error on save
---+
  Reporter:  exo...@gmail.com  | Owner:  nobody 
Status:  new   | Milestone:  1.2
 Component:  Uncategorized |   Version:  SVN
Resolution:|  Keywords:  formats l10n locale
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * needs_better_patch:  => 0
  * summary:  USE_THOUSAND_SEPARATOR breaks forms by separating inline
  primary key values, breaking save =>
  USE_THOUSAND_SEPARATOR breaks forms by
  formatting primary key values, causing error on
  save
  * 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-upda...@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] #13032: USE_THOUSAND_SEPARATOR breaks forms by separating inline primary key values, breaking save

[Django]

#13032: USE_THOUSAND_SEPARATOR breaks forms by separating inline primary key
values, breaking save
-+--
 Reporter:  exo...@gmail.com |   Owner:  nobody
   Status:  new  |   Milestone:  1.2   
Component:  Uncategorized| Version:  SVN   
 Keywords:  formats l10n locale  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 When using USE_THOUSAND_SEPARATOR and NUMBER_GROUPING, number values in
 forms (e.g. those in Django admin) are locale-formatted. Some fields clean
 separators from the value and continue to work, but some don't, causing
 errors when saving forms with inlines, for instance: {{{ invalid literal
 for int() with base 10: '2,978' }}} - in this case, 2978 is the model's
 AutoField value.

 I would strongly reconsider locale-formatting any form values and being
 much more cautious about when to format. Consider that it's reasonable to
 use an IntegerField to store a year, yet we don't separate/group those
 numbers.

-- 
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-upda...@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] #13023: Don't show "+ Add another" in admin inlines when extra = 0

[Django]

#13023: Don't show "+ Add another" in admin inlines when extra = 0
---+
  Reporter:  rasca | Owner:  gabrielhurley
Status:  assigned  | Milestone:  1.2  
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by gabrielhurley):

 Replying to [comment:3 gregplaysguitar]:
 > Another use case which is affected here - I have a flatpages-esque app
 with content stored in a Block model, which has a ForeignKey to Page. When
 a Page is saved, it introspects the selected template to generate the
 required blocks, which can then be edited inline. A page template can
 include any number of blocks, so max_num isn't an option here, but the
 number and type of blocks are also completely dependent on the template,
 so it makes no sense to have "Add another block" at the bottom. Pre-1.2 I
 just set extra=0 and it was fine; now I can't do that.

 It's not entirely clear to me what your code is actually doing, but if
 this patch does not fix your issue, you could try taking the change I
 applied to BaseInlineFormSet and moving it to BaseModelFormSet instead.
 The bug report was about Admin Inlines, though, and I can't guarantee that
 applying this same fix to BaseModelFormSet won't have unintended side-
 effects.

 This patch fixes this ticket. You might want to open a new ticket with
 more detailed information on how to reproduce your bug so we can look at
 it in its own right.

-- 
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-upda...@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] #12896: ModelForm.is_valid() and ModelForm.errors have backwards-incompatible side effects since model validation

[Django]

#12896: ModelForm.is_valid() and ModelForm.errors have backwards-incompatible 
side
effects since model validation
-+--
  Reporter:  lukeplant   | Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Forms   |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by jacob):

 I'll leave the final call to Joseph, but I think he's right and this
 should just be noted in the docs.

-- 
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-upda...@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] #11940: ModelForm evaluates callable default values on form class creation

[Django]

#11940: ModelForm evaluates callable default values on form class creation
+---
  Reporter:  Harm Geerts   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Forms  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #13023: Don't show "+ Add another" in admin inlines when extra = 0

[Django]

#13023: Don't show "+ Add another" in admin inlines when extra = 0
---+
  Reporter:  rasca | Owner:  gabrielhurley
Status:  assigned  | Milestone:  1.2  
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by gregplaysguitar):

 Another use case which is affected here - I have a flatpages-esque app
 with content stored in a Block model, which has a ForeignKey to Page. When
 a Page is saved, it introspects the selected template to generate the
 required blocks, which can then be edited inline. A page template can
 include any number of blocks, so max_num isn't an option here, but the
 number and type of blocks are also completely dependent on the template,
 so it makes no sense to have "Add another block" at the bottom. Pre-1.2 I
 just set extra=0 and it was fine; now I can'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-upda...@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] #12982: Pony: cache.get_or_set()

[Django]

#12982: Pony: cache.get_or_set()
-+--
  Reporter:  Alex| Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:  cache 
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 The race condition is a problem, but as Alex noted on IRC, we should be
 able to avoid this by doing an add() rather than a set().

-- 
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-upda...@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] #10935: forms.ImageField.clean should annotate the object returned by FileField.clean

[Django]

#10935: forms.ImageField.clean should annotate the object returned by
FileField.clean
-+--
  Reporter:  jdunck  | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

  * milestone:  1.2 => 1.3

Comment:

 I'm calling this a feature, and kicking it out of 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-upda...@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] #12791: Setting encoding on EmailMessage does not produce intended result

[Django]

#12791: Setting encoding on EmailMessage does not produce intended result
+---
  Reporter:  oyvind | Owner:  oyvind

Status:  reopened   | Milestone:  1.2   

 Component:  django.core.mail   |   Version:  SVN   

Resolution: |  Keywords:  iso-8859-1 utf-8 
smart_str mail header
 Stage:  Ready for checkin  | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

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

  * stage:  Accepted => 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-upda...@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] #12940: Comments admin should use ungettext instead of ugettext

[Django]

#12940: Comments admin should use ungettext instead of ugettext
--+-
  Reporter:  void | Owner:  nobody
Status:  new  | Milestone:  1.2   
 Component:  django.contrib.comments  |   Version:  SVN   
Resolution:   |  Keywords:  i18n, comments
 Stage:  Ready for checkin| Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #12849: django's development server raises an encoding exception when trying to colorize non-ascii text

[Django]

#12849: django's development server raises an encoding exception when trying to
colorize non-ascii text
+---
  Reporter:  jype   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  django-admin.py runserver  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #12343: manage.py dbshell fails to launch mysql for unix socket

[Django]

#12343: manage.py dbshell fails to launch mysql for unix socket
-+--
  Reporter:  elyon...@gmail.com  | Owner:  nobody   
Status:  new | Milestone:  1.2  
 Component:  django-admin.py |   Version:  1.1  
Resolution:  |  Keywords:  dbshell mysql
 Stage:  Ready for checkin   | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #12229: ImageField.save should be documented upfront and obvious

[Django]

#12229: ImageField.save should be documented upfront and obvious
+---
  Reporter:  freyley| Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.2  
 Component:  Documentation  |   Version:  1.1  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * status:  new => assigned
  * has_patch:  0 => 1

Comment:

 Added a patch that adds a large chunk to the FileField docs regarding the
 publicly available methods that get added by the complex machinations of
 FieldFile. Updates the ImageField docs as well to make it a little more
 obvious that it gets '''everything''' from FileField.

-- 
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-upda...@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] #10099: MySQL 5.0 does not support LIMIT in subqueries

[Django]

#10099: MySQL 5.0 does not support LIMIT in subqueries
---+
  Reporter:  Anossov   | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Marking wontfix: there's plenty of places where Django could generate SQL
 that the database won't support. Abstractions are leaky.

-- 
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-upda...@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] #13031: User class in the auth module should return lastname and firstname as unicode representation

[Django]

#13031: User class in the auth module should return lastname and firstname as
unicode representation
-+--
  Reporter:  Raydiation  | Owner:  nobody   
 
Status:  closed  | Milestone:   
 
 Component:  Authentication  |   Version:  1.1  
 
Resolution:  wontfix |  Keywords:  
unicode,firstname,lastname
 Stage:  Unreviewed  | Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

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

Comment:

 "Annoying" is a matter of taste: I'd find this patch annoying, myself. We
 built the bikeshed and painted it this color; there's no real gain to
 change it 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-upda...@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] #13031: User class in the auth module should return lastname and firstname as unicode representation

[Django]

#13031: User class in the auth module should return lastname and firstname as
unicode representation
-+--
  Reporter:  Raydiation  | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Authentication  |   Version:  1.1  
 
Resolution:  |  Keywords:  
unicode,firstname,lastname
 Stage:  Unreviewed  | Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by Raydiation):

  * needs_better_patch:  => 0
  * summary:  User class in the auth module should return lastname and
  firstname as representation => User class in
  the auth module should return lastname and
  firstname as unicode representation
  * 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-upda...@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] #13031: User class in the auth module should return lastname and firstname as representation

[Django]

#13031: User class in the auth module should return lastname and firstname as
representation
+---
 Reporter:  Raydiation  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Authentication  | Version:  1.1   
 Keywords:  unicode,firstname,lastname  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Its quite annoying to get the Loginname as representation of the User.
 Normally you identify Users by their first and lastname and you if you got
 users with the exact same name just return the loginname too. The unicode
 method should do something like this:


 {{{
 class User(object):

 __unicode__(self):
 if completeName.unique(): # checks if the last and first name
 identify the user
 return "%s %s" % (self.last_name, self.first_name)
 else:
 return "%s %s (%s)" % (self.last_name, self.first_name,
 self.username)
 }}}

-- 
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-upda...@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] #12870: ORM bug with using exclude in conjunction with Q objects

[Django]

#12870: ORM bug with using exclude in conjunction with Q objects
---+
  Reporter:  subsume   | Owner:  nobody   
Status:  new   | Milestone:  1.2  
 Component:  Database layer (models, ORM)  |   Version:  1.1  
Resolution:|  Keywords:  exclude Q
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 I verified that this bug still exists in latest svn. updated console:

 {{{

 >>>
 
Deck.objects.filter(user__username='nammertime').exclude(Q(category='pro')|Q(category='precon')).query.get_compiler('default').as_sql()
 ('SELECT `deck_deck`.`id`, `deck_deck`.`format_id`, `deck_deck`.`name`,
 `deck_deck`.`slug`, `deck_deck`.`user_id`, `deck_deck`.`description`,
 `deck_deck`.`profile_cardinality`, `deck_deck`.`date_added`,
 `deck_deck`.`date_updated`, `deck_deck`.`date_refreshed`,
 `deck_deck`.`is_private`, `deck_deck`.`category`,
 `deck_deck`.`preconstructed_set_id`, `deck_deck`.`cost`,
 `deck_deck`.`view_count_cache`, `deck_deck`.`comment_count_cache`,
 `deck_deck`.`data_generated`, `deck_deck`.`image_token`,
 `deck_deck`.`similar_due`, `deck_deck`.`rating_votes`,
 `deck_deck`.`rating_score` FROM `deck_deck` INNER JOIN `auth_user` ON
 (`deck_deck`.`user_id` = `auth_user`.`id`) WHERE (`auth_user`.`username` =
 %s  AND NOT ((`deck_deck`.`category` = %s  OR `deck_deck`.`category` = %s
 )))', ('nammertime', 'pro', 'precon'))

 >>>
 
Deck.objects.filter(user__username='nammertime').exclude(category='pro').exclude(category='precon').query.get_compiler('default').as_sql()
 ('SELECT `deck_deck`.`id`, `deck_deck`.`format_id`, `deck_deck`.`name`,
 `deck_deck`.`slug`, `deck_deck`.`user_id`, `deck_deck`.`description`,
 `deck_deck`.`profile_cardinality`, `deck_deck`.`date_added`,
 `deck_deck`.`date_updated`, `deck_deck`.`date_refreshed`,
 `deck_deck`.`is_private`, `deck_deck`.`category`,
 `deck_deck`.`preconstructed_set_id`, `deck_deck`.`cost`,
 `deck_deck`.`view_count_cache`, `deck_deck`.`comment_count_cache`,
 `deck_deck`.`data_generated`, `deck_deck`.`image_token`,
 `deck_deck`.`similar_due`, `deck_deck`.`rating_votes`,
 `deck_deck`.`rating_score` FROM `deck_deck` INNER JOIN `auth_user` ON
 (`deck_deck`.`user_id` = `auth_user`.`id`) WHERE (`auth_user`.`username` =
 %s  AND NOT (`deck_deck`.`category` = %s  AND NOT (`deck_deck`.`category`
 IS NULL)) AND NOT (`deck_deck`.`category` = %s  AND NOT
 (`deck_deck`.`category` IS NULL)))', ('nammertime', 'pro', 'precon'))
 >>>

 }}}

 I realize that the tests you can seemed to come up clean, however, there
 is still some burden to explain the extraneous JOINS. Obviously the test
 case isn't close enough to the actual problem. Indeed, the fact that such
 a basic bug can live this long must mean there is a nuance missing. If
 filter(Q()|Q()) was broken, it would have been found in minutes.

-- 
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-upda...@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] #12249: csrf_token not clear in User Authentication docs

[Django]

#12249: csrf_token not clear in User Authentication docs
+---
  Reporter:  drozzy | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.2  
 Component:  Documentation  |   Version:  1.1  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * status:  new => assigned
  * has_patch:  0 => 1
  * summary:  csrf_token not clear in User authentication docs =>
  csrf_token not clear in User Authentication
  docs

Comment:

 Added a patch that adds info on the csrf_token and a link to upgrading
 instructions ahead of the form in question so it won't surprise people (as
 reported in this ticket).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #12811: Tutorial 2 gets into templating details too early

[Django]

#12811: Tutorial 2 gets into templating details too early
+---
  Reporter:  bac| Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.2  
 Component:  Documentation  |   Version:  1.1  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * status:  new => assigned
  * has_patch:  0 => 1
  * summary:  Tutorial suggestion at the end of lesson 2 is inappropriate
  => Tutorial 2 gets into templating details too
  early

Comment:

 Add a patch that clarifies tutorial language and removes premature
 instructions on templating. It's based on the verbiage given by Russell
 above. Thanks Russ!

-- 
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-upda...@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] #13013: Example form in i18n docs is missing {% csrf_token %}

[Django]

#13013: Example form in i18n docs is missing {% csrf_token %}
+---
  Reporter:  anonymous  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.2  
 Component:  Documentation  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * owner:  nobody => gabrielhurley
  * status:  new => assigned
  * has_patch:  0 => 1
  * summary:  Page missing {% csrf_token %} => Example form in i18n docs is
  missing {% csrf_token %}

Comment:

 Added patch that adds the necessary csrf_token. Simple fix.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13014: Document using LANGUAGE_CODE with the cache template tag

[Django]

#13014: Document using LANGUAGE_CODE with the cache template tag
+---
  Reporter:  yml| Owner: 
Status:  new| Milestone:  1.2
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * has_patch:  0 => 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-upda...@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] #13023: Don't show "+ Add another" in admin inlines when extra = 0

[Django]

#13023: Don't show "+ Add another" in admin inlines when extra = 0
---+
  Reporter:  rasca | Owner:  gabrielhurley
Status:  assigned  | Milestone:  1.2  
 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 gabrielhurley):

  * owner:  nobody => gabrielhurley
  * needs_docs:  1 => 0
  * has_patch:  0 => 1
  * status:  new => assigned
  * summary:  Don't show "+ Add another " in admin inlines => Don't show "+
  Add another" in admin inlines when extra = 0

Comment:

 I added a patch which restores the desired behavior by automatically
 setting max_num to the length of the queryset if both max_num and extra
 are zero. The result seems to be completely in line with the expected
 behavior from 1.1 and doesn't introduce any new effects that I can see.
 Overall I love the new "add another" button.

 I also added/updated docs for this, and since this is my fifth or sixth
 patch to Django, I added my name to the contributors list... I hope that's
 okay :-)

 In the larger scope of things, the default for max_num being zero seems
 counter-intuitive. Rather than a value of zero for max_num actually
 meaning that there can be no forms/modelforms/inlines, the value of zero
 is actually just ignored because it's the default. This patch wouldn't be
 necessary if that weren't the case. However, for backwards compatibility I
 understand that changing the default value of max_num is a complete non-
 starter.

-- 
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-upda...@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] #13030: Natural Key deserialization fails on foreign key to field that is itself a foreign key

[Django]

#13030: Natural Key deserialization fails on foreign key to field that is 
itself a
foreign key
---+
 Reporter:  yishaibeeri|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Serialization  | Version:  SVN   
 Keywords:  natural keys   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Attached diff has a test showing this:

 In (nonabstract) model inheritance, the child model's B primary key is not
 the usual integer, but rather a FK to the parent A.

 Suppose model B has defined natural_key() and get_by_natural_key().

 If a third model C has a field that is a foreign key to B, loading it
 using deserialization with natural keys will fail. During creation of the
 C instance (let's call it objC), this is what happens:

  * First, the natural key will be used to successfully construct the
 instance of B (let's call it objB).
  * Then, an assignment is made to set the relevant field of objC to point
 to objB. However, instead of the naive {{{objC.thefield = objB}}}, the
 actual assignment uses the relevant field.rel.field_name to do something
 along the lines of:
 {{{
field_name = field.rel.field_name
objC.thefield_id = getattr(objB, field_name)
 }}}
  * In the usual case where field_name is a simple primary key (such as
 'id'), this works nicely. However,
  * when this field is in itself a foreignkey, the result from getattr is
 an object - the relevant objA(!). This of course throws a nasty exception.

 I have not tried, but it appears this would fail in a similar fashion in
 any case where the target of the first FK (from objC) is itself an FK and
 not a simple field (even without involving inheritance).

 Perhaps the naive approach ({{{objC.thefield = objB}}}) would work better
 for all cases? This is a bit too deep for me, I'm afraid.

-- 
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-upda...@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] #13000: Deprecated code in admin forms triggers string translation too soon

[Django]

#13000: Deprecated code in admin forms triggers string translation too soon
---+
  Reporter:  lgs   | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #12434: django.contrib.admin does not work with blank short_description

[Django]

#12434: django.contrib.admin does not work with blank short_description
---+
  Reporter:  anonymous | Owner:  gabrielhurley
Status:  assigned  | Milestone:  1.2  
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #12260: bug -- CSS class messes up ModelMultipleChoiceField in contrib.admin

[Django]

#12260: bug -- CSS class messes up ModelMultipleChoiceField in contrib.admin
---+
  Reporter:  tiliv | Owner:  tiliv  
 
Status:  assigned  | Milestone:  1.2
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  css, admin, 
ModelMultipleChoiceField
 Stage:  Ready for checkin | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * stage:  Accepted => 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-upda...@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] #12235: MultiValueDictKeyError when editing Inline objects

[Django]

#12235: MultiValueDictKeyError when editing Inline objects
---+
  Reporter:  br...@playfirst.com   | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:  invalid   |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 It's clear to me from the description that this is an improperly written
 uuid field class. As suggested, the fix goes there.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #10751: Admin actions not calling model's delete() method

[Django]

#10751: Admin actions not calling model's delete() method
-+--
  Reporter:  msurdi  | Owner:  nobody
Status:  closed  | Milestone:  1.2   
 Component:  django.contrib.admin|   Version:  SVN   
Resolution:  duplicate   |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

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

Comment:

 Now that the docs are in, I'm closing this as a dup of #11022. Please open
 another ticket for the other thing, if it's indeed a 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-upda...@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] #12882: jQuery.noConflict() in admin brokes site specific code with jQuery

[Django]

#12882: jQuery.noConflict() in admin brokes site specific code with jQuery
---+
  Reporter:  krej...@i3.cz | Owner:  jezdez  
Status:  assigned  | Milestone:  1.2 
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  jQuery admin
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by jezdez):

 In the attached patch I'm referring to the part of jQuery's documentation:

 "If necessary, we can free up the jQuery name as well by passing true as
 an argument to the method. This is rarely necessary, and if we must do
 this (for example, if we need to use multiple versions of the jQuery
 library on the same page), we need to consider that most plug-ins rely on
 the presence of the jQuery variable and may not operate correctly in this
 situation."

 Question is, can we test this somehow? Does it solve your issue, krejcik?

-- 
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-upda...@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] #13026: Problem with selecting related object from popup window, opened by lens icon in dynamic created inline row

[Django]

#13026: Problem with selecting related object from popup window, opened by lens
icon in dynamic created inline row
---+
  Reporter:  ramusus   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ramusus):

 The problem is not a shift between number of row and id of elements inside
 this row for me. The problem is starting, when I create new rows
 dynamically and these rows has a lookup lens icon with link. Id for this
 link generated incorrectly and it's the reason of this ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13026: Problem with selecting related object from popup window, opened by lens icon in dynamic created inline row

[Django]

#13026: Problem with selecting related object from popup window, opened by lens
icon in dynamic created inline row
---+
  Reporter:  ramusus   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by stefanfoulis):

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

Comment:

 it seems that the numbering on some fields is off by one. it's tricky,
 because the rows are numbered starting with 1 in the visible parts and the
 class of the element that surrounds each row. But the actual id's on the
 rows of the formset start with 0.
 Adding a '-1' in the right spot in inlines.js fixed issue for me (with
 dropdown foreignkeys, the '+' add button and the raw id widget).
 I attached a patch.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #12773: Update FAQ to indicate supported Python versions

[Django]

#12773: Update FAQ to indicate supported Python versions
+---
  Reporter:  russellm   | Owner:  kmtracey
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.1 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

  * owner:  djansoft => kmtracey
  * status:  reopened => new
  * milestone:  1.2 =>

Comment:

 Python 2.7 is targeted for June, so it's unlikely (I hope) we need to say
 anything in the FAQ before 1.2 goes out. We can update the FAQ when Python
 2.7 is released.

-- 
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-upda...@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] #13029: Exception Value is empty with a HTMLParser.HTMLParseError

[Django]

#13029: Exception Value is empty with a HTMLParser.HTMLParseError
+---
  Reporter:  jedie  | Owner:  nobody   
Status:  new| Milestone:   
 Component:  Uncategorized  |   Version:  SVN  
Resolution: |  Keywords:  traceback
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 This appears to be a Python2.6-only problem. 2.4, 2.5, and 2.7 (alpha 2)
 all display a non-empty Exception Value for these exceptions. For some
 reason I have not tracked down, on Python 2.6.4, `unicode()` applied to
 one of these exceptions produces an empty string. On earlier Pythons we
 don't attempt to apply `unicode()` to the exception since it doesn't have
 a `__unicode__` attribute -- we display essentially `unicode(str(e))`
 where `e` is the exception. On 2.7 alpha 2 some change has been made so
 that `unicode(e)` for one of these gets routed to the HTMLParseError
 `__str__` override. Possibly whatever change in Python that did that will
 also appear in the next release of 2.6, but since I haven't tracked down
 what change in Python is responsible for the difference I can't say that
 for sure.

 I'm tempted to close this as invalid since it's really looking to me like
 a bug in Python, not Django. But these sorts of failures to display debug
 info are pretty annoying, so if there's something we could do to fix it in
 Django maybe we should. I'm just not sure what that would be.

-- 
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-upda...@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] #13029: Exception Value is empty with a HTMLParser.HTMLParseError

[Django]

#13029: Exception Value is empty with a HTMLParser.HTMLParseError
---+
 Reporter:  jedie  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords:  traceback  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In the settings.DEBUG Traceback page is the Exception Value empty if a
 HTMLParser.HTMLParseError was raised.

 e.g.: Put this in a view:
 {{{
 from HTMLParser import HTMLParseError
 raise HTMLParseError("FooBar Error message", (1, 2))
 }}}

 Normaly, the exception value should be:
 {{{
 FooBar Error message, at line 1, column 3
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #12962: Broken Admin Delete Action With Confirmation

[Django]

#12962: Broken Admin Delete Action With Confirmation
---+
  Reporter:  leveille  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  django.contrib.admin  |   Version:  1.2-beta
Resolution:|  Keywords:  admin delete
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Comment (by blinkylights):

 @skevy

 Oh, no... there was definitely a problem before the patch.  The patch
 makes how we're differentiating between action POSTs and list_editable
 POSTs more explicit (and it works). In doing so, it also reveals why we
 actually need to be even ''more'' explicit to cover cases where users
 might intend to launch an action, but do a list_editable submit, or vice-
 versa. So no: the patch is fine, it just needs to do a little more.

 Think I have something that works, but you're absolutely right - we need
 to get some up-to-date tests written so this doesn't come back up.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13014: Document using LANGUAGE_CODE with the cache template tag

[Django]

#13014: Document using LANGUAGE_CODE with the cache template tag
+---
  Reporter:  yml| Owner: 
Status:  new| Milestone:  1.2
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * status:  assigned => new
  * component:  Template system => Documentation
  * summary:  Cache templatetag is not locale aware => Document using
  LANGUAGE_CODE with the cache template tag
  * owner:  SmileyChris =>
  * needs_docs:  1 => 0
  * has_patch:  1 => 0
  * stage:  Design decision needed => Accepted

Comment:

 Good point, Jacob. Definitely just a documentation job.

-- 
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-upda...@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] #11903: WSGIRequest.path not quoted properly

[Django]

#11903: WSGIRequest.path not quoted properly
+---
  Reporter:  ianb   | Owner:  krisneuharth
Status:  new| Milestone:  1.2 
 Component:  HTTP handling  |   Version:  1.1 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  1   
Needs_better_patch:  1  |  
+---
Changes (by jacob):

  * needs_better_patch:  0 => 1

Comment:

 Need a test for this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #11449: Performance regression loading from fixtures in 1.1 & trunk

[Django]

#11449: Performance regression loading from fixtures in 1.1 & trunk
+---
  Reporter:  novalis| Owner:  nobody
Status:  reopened   | Milestone:  1.3   
 Component:  Serialization  |   Version:  1.1-beta-1
Resolution: |  Keywords:  perf  
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

  * keywords:  => perf
  * milestone:  1.2 => 1.3

Comment:

 With 1.2 in the final stages and no more information about why this is
 slow, I'm booting it out of the milestone. Fixture loading isn't critical
 in deployment, so this shouldn't block the release.

-- 
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-upda...@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] #13014: Cache templatetag is not locale aware

[Django]

#13014: Cache templatetag is not locale aware
-+--
  Reporter:  yml | Owner:  SmileyChris
Status:  assigned| Milestone:  1.2
 Component:  Template system |   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  1   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by jacob):

 Doesn't the i18n context processor put `LANGUAGE_CODE`in the context?
 Seems to me that's the right approach -- "explicit is better than
 implicit". Any reason we should do anything more than a doc addition?

-- 
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-upda...@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] #13028: Introspection doesn't work on mysql 4.1

[Django]

#13028: Introspection doesn't work on mysql 4.1
--+-
 Reporter:  pczapla   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 When I ran introspection against mysql 4.1, I've got the following error:

 {{{
  python manage.py  inspectdb
 # This is an auto-generated Django model module.
 # You'll have to do the following manually to clean this up:
 # * Rearrange models' order
 # * Make sure each model has one field with primary_key=True
 # Feel free to rename the models, but don't rename db_table values or
 field names.
 #
 # Also note: You'll have to insert the output of 'django-admin.py
 sqlcustom [appname]'
 # into your database.

 from django.db import models

 class Wrk(models.Model):
 Traceback (most recent call last):
   File "manage.py", line 15, in 
 execute_manager(settings)
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/__init__.py", line 438, in execute_manager
 utility.execute()
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/base.py", line 195, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/base.py", line 222, in execute
 output = self.handle(*args, **options)
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/commands/inspectdb.py", line 22, in
 handle_noargs
 for line in self.handle_inspection(options):
   File "/home/pczapla/test/libsdjango-
 trunk/django/core/management/commands/inspectdb.py", line 47, in
 handle_inspection
 relations = connection.introspection.get_relations(cursor, table_name)
   File "/home/pczapla/test/libsdjango-
 trunk/django/db/backends/mysql/introspection.py", line 64, in
 get_relations
 AND referenced_column_name IS NOT NULL""", [table_name])
   File "/home/pczapla/test/libsdjango-trunk/django/db/backends/util.py",
 line 19, in execute
 return self.cursor.execute(sql, params)
   File "/home/pczapla/test/libsdjango-
 trunk/django/db/backends/mysql/base.py", line 86, in execute
 return self.cursor.execute(query, args)
   File "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 173,
 in execute
 self.errorhandler(self, exc, value)
   File "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line
 36, in defaulterrorhandler
 raise errorclass, errorvalue
 django.db.utils.DatabaseError: (1146, "Table
 'information_schema.key_column_usage' doesn't exist")
 }}}

 To fix this problem I've added the DatabaseError to the "except" statement
 in get_relations table.
 The patch is attached.

-- 
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-upda...@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] #13027: serializer won't serialize an empty queryset or an iterator with a None item

[Django]

#13027: serializer won't serialize an empty queryset or an iterator with a None
item
---+
 Reporter:  adrian_nye |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Ideally, I'd like to be able to serialize any queryset (including an empty
 one) or a list of django objects including one that is None,
 and when I deserialize I should get the same queryset or the same list.

 What happens now is you get the error 'NoneType' object has no attribute
 '_meta'.

 If that is not possible, then it should be documented that an empty
 queryset or an iterator containing a None object cannot be serialized.

-- 
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-upda...@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] #13026: Problem with selecting related object from popup window, opened by lens icon in dynamic created inline row

[Django]

#13026: Problem with selecting related object from popup window, opened by lens
icon in dynamic created inline row
--+-
 Reporter:  ramusus   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 With inline rows created by django's template everithing is ok, but I
 found problem with rows created dynamically. Problem with changing dynamic
 id in html containers of created row. Id of lens-icon-link defines
 incorrectly.

-- 
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-upda...@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] #9847: hardcoded string in core/handlers/base.py

[Django]

#9847: hardcoded string in core/handlers/base.py
-+--
  Reporter:  drakkan | Owner: 
Status:  new | Milestone:  1.3
 Component:  Core framework  |   Version:  1.0
Resolution:  |  Keywords: 
 Stage:  Accepted| Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  1   |  
-+--
Changes (by adamnelson):

  * needs_better_patch:  0 => 1

Comment:

 I take back what I said about not having a message at all.

  1. It shouldn't be hardcoded in base.py, maybe it should be in
 source:django/trunk/django/http/__init__.py ?
  1. All the non-200 HTTP errors should derive from a master error class.
 Right now it's kind of a hodge-podge it seems.

 I agree that milestone:1.3 is best.

-- 
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-upda...@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] #13006: Add order_by with sql LOWER() support

[Django]

#13006: Add order_by with sql LOWER() support
---+
  Reporter:  Raydiation| Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  
sql,order,lower
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 Yes to the use case, no to the proposed API. A better approach would be a
 variation on #10972: allow annotation of modified columns in a query, and
 then allow ordering on those columns - for example:
 {{{
 
MusicCollection.objects.annotate(lc_artist_name=LowerCase('artist__name')).order_by(lc_artist_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-upda...@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] #13007: Django fails to log in when a cookie is set on the same domain containing a colon

[Django]

#13007: Django fails to log in when a cookie is set on the same domain 
containing a
colon
+---
  Reporter:  Warlax | Owner:  nobody 
Status:  closed | Milestone: 
 Component:  HTTP handling  |   Version:  1.1
Resolution:  invalid|  Keywords:  cookies
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 A colon *should* be a valid value in a cookie; you'll need to provide a
 specific failing test case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13025: Test runner should print failed test path in format that is accepted by `manage.py test ...`

[Django]

#13025: Test runner should print failed test path in format that is accepted by
`manage.py test ...`
---+
 Reporter:  zimnyx |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When I run all test and some of them fail I see
 {{{
 FAIL: "test_function_name (projectname.appname.tests.TestCaseName)".
 }}}

 Now when I want to run this single test (which happens very often) I need
 to manualy compose parameter for `manage.py test` like this:
 {{{
 manage.py test appname.TestCaseName.test_function_name
 }}}
 It would be handy if test runner printed failed test path, that can be
 directly used for `manage.py test`:
 {{{
 FAIL: test_function_name (appname.TestCaseName.test_function_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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

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

[Django]

#13008: @never_cache decorator should add  'no-cache' & 'must-revalidate'
---+
  Reporter:  harm  | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Cache system  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 1
  * 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-upda...@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] #13009: provide django.forms field type info for use in templates

[Django]

#13009: provide django.forms field type info for use in templates
---+
  Reporter:  tvon  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Forms |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Broadly the idea has merit, but it needs a bit of finesse - specifically,
 what determines the "type" of the field? Do we just use the type of the
 input element on the widget? What do we do in the case of multi-widgets?

 Unfortunately, the solution used in admin isn't a great reference point.
 Admin has control of all it's widgets, and the way in which they are used.
 This isn't true of the broader widget framework, which must integrate with
 arbitrary external widgets, used in unknown ways.

-- 
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-upda...@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] #12974: Admin docs omits several methods for a Model

[Django]

#12974: Admin docs omits several methods for a Model
---+
  Reporter:  jabapyth  | Owner:  jabapyth   
   
Status:  reopened  | Milestone: 
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  admin, docs, 
method, admindocs
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  1  
   
Needs_better_patch:  1 |  
---+
Comment (by jabapyth):

 Could you explain the 'redundant' comment? The function ''must'' not have
 any required arguments (at least that is my impression of the desired
 behavior), and the check is therefore still necessary. Are you referring
 to some line other than the one that I modified?

-- 
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-upda...@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] #13011: Clear Cache tag for consideration

[Django]

#13011: Clear Cache tag for consideration
---+
  Reporter:  redcoelho | Owner:  nobody  
Status:  closed| Milestone:  
 Component:  Cache system  |   Version:  1.2-beta
Resolution:  wontfix   |  Keywords:  
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm going to mark this wontfix because it's starting to get into
 'programming logic in the template' territory.

-- 
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-upda...@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] #13013: Page missing {% csrf_token %}

[Django]

#13013: Page missing {% csrf_token %}
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * milestone:  => 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-upda...@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] #13016: Invalid ForeignKey ids in fixtures do not cause any error messages

[Django]

#13016: Invalid ForeignKey ids in fixtures do not cause any error messages
---+
  Reporter:  Art   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Testing framework |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13017: generic relation generates needless join

[Django]

#13017: generic relation generates needless join
---+
  Reporter:  MS| Owner:  nobody 

Status:  new   | Milestone:  1.2

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

Resolution:|  Keywords:  database 
joins generic relation
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 This is possibly a regression caused by the recent m2m changes; needs
 further investigation.

-- 
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-upda...@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] #13019: create_update: proxy object displayed instead of model verbose name

[Django]

#13019: create_update: proxy object displayed instead of model verbose name
---+
  Reporter:  Beuc  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  1 |  
---+
Changes (by russellm):

  * needs_better_patch:  0 => 1
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  0 => 1
  * stage:  Unreviewed => Accepted

Comment:

 It's not a bug to require unicode strings when defining unicode text.
 However, the return value for create_update is clearly problematic. I'm
 not sure just making the string unicode is the right response; HTTP
 responses need to be ascii strings.

-- 
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-upda...@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] #13023: Don't show "+ Add another " in admin inlines

[Django]

#13023: Don't show "+ Add another " in admin inlines
---+
  Reporter:  rasca | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 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-upda...@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] #13020: Django session documentation is wrong

[Django]

#13020: Django session documentation is wrong
+---
  Reporter:  bryan  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 You *should* provide a key if you know which session you want to use. If
 provide a session key, Django will use that key specifically. If you omit
 the key, one will be generated. However, as far as I can tell, the fact
 that a session key will be generated if one isn't provided isn't a
 documented behaviour.

-- 
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-upda...@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] #13022: when saving a model with m2m field in the admin, 'clear' and 'add' m2m_changed signals are fired even when there is no change.

[Django]

#13022: when saving a model with m2m field in the admin, 'clear' and 'add'
m2m_changed signals are fired even when there is no change.
---+
  Reporter:  benc  | Owner:  nobody 
 
Status:  closed| Milestone:  1.2
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  signals, 
m2m_changed
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm going to call this working as intended.

 The admin code is doing an assignment of the form obj.m2m = [new values],
 which internally is 2 signals - clear and add signal. This is completely
 accurate behaviour, and there isn't much we can do to fix this. In order
 to avoid sending the signals, we need to query the database to do a diff
 between submitted values and new values, which is potentially an expensive
 operation.

-- 
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-upda...@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] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by shai):

 Replying to [comment:20 ubernostrum]:
 > A patch which wasn't ready for 1.1 and hasn't been updated since
 probably isn't ready for 1.2.
 >

 A substantial part of the approach was rejected -- core developers decided
 that the negative
 value of an added line in the default settings.py was larger than the
 positive value of fixing
 the problematic behavior in a backwards-compatible way.

 > (also, a better solution might just be to document that if you're doing
 things in raw SQL you should manually inform the transaction middleware by
 setting the transaction to dirty)

 This has already been done, but it only "solves" part of the problem. The
 part where, by default, the middleware and decorator leave the transaction
 pending at the end of the request is not fixed. This can still cause data
 loss and corruption, depending on things like transaction isolation level
 and support of nested transactions in the database backend. Further, those
 would be "phantom bugs" -- hard to reproduce, because they depend on the
 allocation of threads to a stream of requests.

 The correct behavior, clearly, is to close all transactions, whether by
 commit or rollback. Current behavior is a bug which needs to be fixed.

 Since transactions are deep, and changing their behavior might break user
 applications, I suggested (perhaps not as clearly as I should have) a
 three-step path towards correct behavior:

  1. Make new projects behave correctly, keep behavior for old ones, tell
 people they need to adapt (by adding settings.py var)
  1. Make all projects behave correctly, unless explicitly overridden
 (removing var from default settings.py, but still supporting both values)
  1. Cease support for the above override

 In his replies above, Russel effectively says we should either jump
 straight to the end of the path or keep living with the bug. My
 [comment:18 reply] to that went unanswered. If you'd consider a patch
 which just always closes transactions, just say so, and I'll provide one.

 Thanks,
 Shai.

-- 
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-upda...@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] #13024: Signal sent on application startup

[Django]

#13024: Signal sent on application startup
-+--
  Reporter:  wojteks | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 This general has come up several times in the past, but I'm not aware of a
 ticket covering the problem. There are some issues to consider - not the
 least of which is when exactly to send the signal - but the general idea
 is sound and should be addressed.

-- 
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-upda...@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] #12914: Use yaml faster C implementation when available

[Django]

#12914: Use yaml faster C implementation when available
+---
  Reporter:  Beuc   | Owner:  nobody
Status:  new| Milestone:
 Component:  Serialization  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Beuc):

 This is more a bug-fix than a feature IMHO.
 I'd recommend including it in 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-upda...@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] #12747: Custom HTTP status reason phrases are not supported

[Django]

#12747: Custom HTTP status reason phrases are not supported
+---
  Reporter:  Gustavo| Owner:  gisle 

Status:  new| Milestone:

 Component:  HTTP handling  |   Version:  1.1   

Resolution: |  Keywords:  http status, http status 
reason, http status reason phrase
 Stage:  Accepted   | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

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

 @Gustavo:

 Is there any condition under which the existing implementation will raise
 an error or cause data loss in the absence of a custom status message?

 Is there any standard that is violated by not allowing a custom status
 message?

 The answer to both of these questions is No. Therefore, this isn't a bug
 fix. It's a feature request.

 It may be an extremely useful new feature, but that doesn't change the
 fact that it is still a feature, and Django 1.2 is feature frozen.

-- 
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-upda...@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] #12747: Custom HTTP status reason phrases are not supported

[Django]

#12747: Custom HTTP status reason phrases are not supported
+---
  Reporter:  Gustavo| Owner:  gisle 

Status:  new| Milestone:

 Component:  HTTP handling  |   Version:  1.1   

Resolution: |  Keywords:  http status, http status 
reason, http status reason phrase
 Stage:  Accepted   | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

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

 Replying to [comment:5 ubernostrum]:
 > 1.2 is feature-frozen, moving this feature request off the milestone.

 This can hardly be a feature. It's a fix for partially broken HTTP
 support.

-- 
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-upda...@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] #8960: "View on site" does not work if contrib.sites is not installed

[Django]

#8960: "View on site" does not work if contrib.sites is not installed
---+
  Reporter:  bmihelac  | Owner:  adrian
Status:  assigned  | Milestone:  1.2   
 Component:  Contrib apps  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by floledermann):

 I just looked into this - in my opinion a much simpler patch is
 sufficient:


 {{{
 --- django/contrib/contenttypes/views.py
 +++ django/contrib/contenttypes/views.py
 @@ -1,6 +1,6 @@
  from django import http
  from django.contrib.contenttypes.models import ContentType
 -from django.contrib.sites.models import Site
 +from django.contrib.sites.models import Site, RequestSite
  from django.core.exceptions import ObjectDoesNotExist

  def shortcut(request, content_type_id, object_id):
 @@ -54,7 +54,10 @@
  # Fall back to the current site (if possible).
  if object_domain is None:
  try:
 -object_domain = Site.objects.get_current().domain
 +if Site._meta.installed:
 +object_domain = Site.objects.get_current().domain
 +else:
 +current_site = RequestSite(request).domain
  except Site.DoesNotExist:
  pass

 }}}

 If an explicit relationship to Site objects is established in a model
 (this is covered by the lines above my changes) it could be argued that
 the method should fail if the sites app is not installed.

 Unfortunately i do not have the infrastructure here to create a real patch
 against the trunk and run tests... I hope this helps, can somebody help to
 get this into 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-upda...@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] #13024: Signal sent on application startup

[Django]

#13024: Signal sent on application startup
+---
 Reporter:  wojteks |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I'd like to perform certain actions whenever my application starts running
 (via runserver or runfcgi, for each backend spawned).  I don't want to do
 it in the middleware or on the request_started signal, because that's not
 elegant.  So the best way would be for Django to send a
 'server_initialized' signal whenever the server is finished preparing all
 the data, right before the listen call on the socket.

-- 
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-upda...@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] #8960: "View on site" does not work if contrib.sites is not installed

[Django]

#8960: "View on site" does not work if contrib.sites is not installed
---+
  Reporter:  bmihelac  | Owner:  adrian
Status:  assigned  | Milestone:  1.2   
 Component:  Contrib apps  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by floledermann):

  * version:  1.0 => 1.1
  * component:  Core framework => Contrib apps
  * milestone:  => 1.2

Comment:

 This is still present in 1.1.1, can we get this bug fixed in 1.2 please?

 However, the patch would probably have to be rewritten using RequestSite,
 which was probably invented after the patch for this issue had been
 submitted.

-- 
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-upda...@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] #10608: Support RequestSite along with Sites.objects.get_current() in contrib

[Django]

#10608: Support RequestSite along with Sites.objects.get_current() in contrib
---+
  Reporter:  hvendelbo | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by floledermann):

 Btw the bug for the "View on site" issue is #8960 - also still not
 resolved, and much older than this issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #10608: Support RequestSite along with Sites.objects.get_current() in contrib

[Django]

#10608: Support RequestSite along with Sites.objects.get_current() in contrib
---+
  Reporter:  hvendelbo | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by floledermann):

  * version:  1.0 => 1.1

Comment:

 I would classify this as a bug, not a feature. Without using sites the
 "View on site" link is generated in the admin, but fails with an error
 when clicked - isn't that a bug?

 However this should probably be broken down into several bugs dealing with
 each contrib app, then the consequences of this bug could also be
 discussed in more detail. Too late for 1.2 anyway, probably.

-- 
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-upda...@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.