Re: [Django] #13473: BRCPFField and BRCNPJField updates for localflavor.br

[Django]

#13473: BRCPFField and BRCNPJField updates for localflavor.br
-+--
  Reporter:  chronos | Owner:  chronos  
Status:  new | Milestone:  1.3  
 Component:  django.contrib.localflavor  |   Version:  SVN  
Resolution:  |  Keywords:  CPF, CNPJ
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by chronos):

 added some more tests, fixed validations and default values of fields.

-- 
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] #3213: Django should have OpenID implemented in django.contrib.auth

[Django]

#3213: Django should have OpenID implemented in django.contrib.auth
-+--
  Reporter:  d...@simon.net.nz| Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Contrib apps|   Version:  
Resolution:  wontfix |  Keywords:  openId, auth
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

 * cc: d...@simon.net.nz (removed)

-- 
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] #3213: Django should have OpenID implemented in django.contrib.auth

[Django]

#3213: Django should have OpenID implemented in django.contrib.auth
-+--
  Reporter:  d...@simon.net.nz| Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Contrib apps|   Version:  
Resolution:  wontfix |  Keywords:  openId, auth
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 Replying to [comment:17 amanjsingh]:
 > are we going to get this OpenID implementation in django.contrib.auth?

 As stated before, please stop re-opening.  Bring this up as a solid
 proposal on django-developers.  Also, look up the definition of django-
 contrib http://jacobian.org/writing/what-is-django-contrib/ - based on the
 comments above, there isn't one solid implementation or de-facto standard.

-- 
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] #3213: Django should have OpenID implemented in django.contrib.auth

[Django]

#3213: Django should have OpenID implemented in django.contrib.auth
-+--
  Reporter:  d...@simon.net.nz| Owner:  nobody  
Status:  reopened| Milestone:  
 Component:  Contrib apps|   Version:  
Resolution:  |  Keywords:  openId, auth
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by amanjsingh):

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

Comment:

 are we going to get this OpenID implementation in django.contrib.auth?

-- 
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] #6362: Remove blank spaces with strip when validating the data

[Django]

#6362: Remove blank spaces with strip when validating the data
-+--
  Reporter:  marinho | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Forms   |   Version:  SVN  
Resolution:  |  Keywords:  blank space strip
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by paulc):

 * cc: pa...@mozilla.com (added)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #3785: admin does not valid object id values before using them in database queries

[Django]

#3785: admin does not valid object id values before using them in database 
queries
---+
  Reporter:  anonymous | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  admin, urls, 
invalid url
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by crucialfelix):

 * cc: crucialfe...@gmail.com (added)

Comment:

 I get this coming through all the time.
 /admin/nsmailings/maillistings/javascripts/t_tip.js/

 no idea what crap browser generates this stuff, I don't even have this
 javascripts/t_tip.js anywhere on my site.

 Its an easy fix, just add ValueError to the caught exceptions :

 {{{
 def get_object(self, request, object_id):
 """
 Returns an instance matching the primary key provided. ``None``
 is
 returned if no match is found (or the object_id failed validation
 against the primary key field).
 """
 queryset = self.queryset(request)
 model = queryset.model
 try:
 object_id = model._meta.pk.to_python(object_id)
 return queryset.get(pk=object_id)
 except (model.DoesNotExist, ValidationError,ValueError):
 return None
 }}}

 line 387, django/contrib/admin/options.py

-- 
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] #13608: Clarify failure of lookups when argument to lookup is not an int

[Django]

#13608: Clarify failure of lookups when argument to lookup is not an int
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The docs for templating api say the following:

 {{{

 Dots have a special meaning in template rendering. A dot in a variable
 name signifies lookup. Specifically, when the template system encounters a
 dot in a variable name, it tries the following lookups, in this order:

 * Dictionary lookup. Example: foo["bar"]
 * Attribute lookup. Example: foo.bar
 * Method call. Example: foo.bar()
 * List-index lookup. Example: foo[bar]

 }}}

 From this, I was under the impression that the following would work...

 View...
 {{{
 context = dict(sizes=['SM', 'MD', LG'], available= {'SM': True, 'MD' :
 False, 'LG' : False})
 return render_to_response('index.html', context)
 }}}

 Template...
 {{{
 {% for size in sizes %}
{% if apparel.size %}
{{size}} is available!
{% else %}
{{size}} is not available!
{% endif %}
 {% endfor %}
 }}}

 I had to look into the code to discover that when the docs mean list-
 lookup foo[bar], that if bar is a string, it will not do a dictionary
 lookup. Clarifying that the list lookup will only work with integers would
 be helpful.

-- 
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] #13602: path for fix hardcode 'django_language'

[Django]

#13602: path for  fix  hardcode 'django_language'
---+
  Reporter:  ablis | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Internationalization  |   Version:  1.2
 
Resolution:  invalid   |  Keywords:  
LANGUAGE_COOKIE_NAME
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by ablis):

 And for the end. My opinion is that add on the default settings the
 constant like SESSION_LANGUAGE_NAME ='django_language' will be more
 correct.

-- 
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] #13607: Admin date_hierarchy drill-down should auto-initialise to appropriate level

[Django]

#13607: Admin date_hierarchy drill-down should auto-initialise to appropriate 
level
---+
 Reporter:  DrMeers|   Owner:
   Status:  new|   Milestone:  1.3   
Component:  User Experience| Version:  SVN   
 Keywords:  admin, date_hierarchy  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Say you have a model with a {{{date_hierarchy}}} field selected in the
 {{{ModelAdmin}}}, but the dates so far only span a few days. Instead of
 seeing the year displayed, then clicking it to show the month, then
 clicking it to show the days, perhaps it would be a good idea to
 initialise it based on the span of dates to show the first level with
 multiple options. That is, if all the dates are in one month, show the
 day-level drill-down initially. If two months are spanned, but in the same
 year, show the month-level drill down initially. If multiple years are
 indeed spanned, then start with the year-level interface.

 Similarly to how {{{list_filter}}}s intelligently show/hide themselves
 based on available data.

 Happy to code this, just wanted to get my thoughts down first.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13579: None gets ignored by __in filter

[Django]

#13579: None gets ignored by __in filter
---+
  Reporter:  outofculture  | Owner:  gruszczy
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.2 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by gruszczy):

  * owner:  nobody => gruszczy

-- 
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] #13579: None gets ignored by __in filter

[Django]

#13579: None gets ignored by __in filter
---+
  Reporter:  outofculture  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gruszczy):

  * has_patch:  0 => 1

Comment:

 I don't know, whether this is a way to go, so I would appreciate any
 advice on the patch and would be happy to work more on it, if required.

-- 
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] #4979: Admin does not allow removal of an image from an ImageField after it has been set, even if null=True and blank=True

[Django]

#4979: Admin does not allow removal of an image from an ImageField after it has
been set, even if null=True and blank=True
---+
  Reporter:  robvdl| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:  ImageField
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

 * cc: kmike (added)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13602: path for fix hardcode 'django_language'

[Django]

#13602: path for  fix  hardcode 'django_language'
---+
  Reporter:  ablis | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Internationalization  |   Version:  1.2
 
Resolution:  invalid   |  Keywords:  
LANGUAGE_COOKIE_NAME
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by ablis):

 Oops... Sorry for waste your time. My mistake... different constants with
 the same 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] #13606: admin raw_id_fields fail to check against non-numerical input

[Django]

#13606: admin raw_id_fields fail to check against non-numerical input
---+
  Reporter:  petrikuitti...@yahoo.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by petrikuitti...@yahoo.com):

 Replying to [comment:1 kmtracey]:
 > Isn't this #13149? We only need one ticket to track getting it fixed.

 Yes. It is the same issue indeed. Unfortunately the patch in #13149
 doesn't solve the problem in Django-1.2.1. I don't know why. The patch
 works for Django-1.2-beta though.

-- 
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] #13149: ForeignKeyRawIdWidget doesn't handle invalid values

[Django]

#13149: ForeignKeyRawIdWidget doesn't handle invalid values
---+
  Reporter:  acdha | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.1  
Resolution:|  Keywords:  raw_id_fields
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  1
Needs_better_patch:  0 |  
---+
Comment (by petrikuitti...@yahoo.com):

 Sorry for opening a new ticket (#13606). This is the same thing.
 HOWEVER this problem still persists in Django-1.2.1. The above patch
 solves
 the problem in Django-1.2-beta 1, but it still gives a ValueError in
 Django-1.2.1.
 We need a better 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] #13606: admin raw_id_fields fail to check against non-numerical input

[Django]

#13606: admin raw_id_fields fail to check against non-numerical input
---+
  Reporter:  petrikuitti...@yahoo.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 Isn't this #13149? We only need one ticket to track getting it fixed.

-- 
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] #11112: Formsets not supported as steps in FormWizard

[Django]

#2: Formsets not supported as steps in FormWizard
--+-
  Reporter:  hlecuanda   | Owner:  nobody  
  
Status:  new  | Milestone:  
  
 Component:  django.contrib.formtools |   Version:  SVN 
  
Resolution:   |  Keywords:  
FormWizard FormSet
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by nfg):

 * cc: n...@gjerull.net (added)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13606: admin raw_id_fields fail to check against non-numerical input

[Django]

#13606: admin raw_id_fields fail to check against non-numerical input
--+-
 Reporter:  petrikuitti...@yahoo.com  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Inputting a non-numerical value in a foreign key field using
 raw_input_fields produces a ValueError exception in django admin.
 E.g write "wer" to any foreign key field, which has been declared with
 raw_input_fields fails:

 {{{
 Django Version: 1.2.1
 Exception Type: ValueError
 Exception Value:
 invalid literal for int() with base 10: 'wer'
 }}}


 Using Django 1.2-beta I was able to fix this bug by simply appending these
 two lines to
 django/contrib/admin/widgets.py label_for_value()-function:


 {{{
 def label_for_value(self, value):
 key = self.rel.get_related_field().name
 try:
 obj = self.rel.to._default_manager.using(self.db).get(**{key:
 value})
 except self.rel.to.DoesNotExist:
 return ''
 # simple fix
 except ValueError:
 return ''
 # end of fix
 return '%s' % escape(truncate_words(obj,
 14))
 }}}


 Now in Django 1.2.1 this fix unfortunately doesn't work.

-- 
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] #13603: module_has_submodule fails when package is of type module

[Django]

#13603: module_has_submodule fails when package is of type module
+---
  Reporter:  eruq...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 This was reported [http://code.djangoproject.com/ticket/11696#comment:12
 here] also, but there was no follow-up on why the odd thing was in
 INSTALLED_APPS. Since silently ignoring nonsense listed in INSTALLED_APPS
 seems like maybe a bad idea, I didn't "fix" it. But if there's enough of
 these cases out there perhaps we should just silently ignore it. I would
 prefer, though, to understand why people have these things that are not
 apps listed in INSTALLED_APPS

-- 
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] #13165: Display edit link beside add button for ForeignKey fields in admin

[Django]

#13165: Display edit link beside add button for ForeignKey fields in admin
--+-
  Reporter:  DrMeers  | Owner:  DrMeers 
   
Status:  new  | Milestone:  1.3 
   
 Component:  User Experience  |   Version:  SVN 
   
Resolution:   |  Keywords:  admin foreign key edit 
link
 Stage:  Accepted | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Changes (by DrMeers):

  * version:  1.1 => SVN

-- 
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] #12421: Foreign Key on Non-Primary Field fails due to lack of Index on Related Field w/ MySQL

[Django]

#12421: Foreign Key on Non-Primary Field fails due to lack of Index on Related
Field w/ MySQL
---+
  Reporter:  anonymous | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by clouserw):

 * cc: clous...@gmail.com (added)
  * status:  closed => reopened
  * resolution:  worksforme =>

Comment:

 I can reproduce this with the following model:

 {{{
 from django.db import models

 class Item(models.Model):
 license = models.ForeignKey('License', to_field="name", null=True)

 class Meta:
 db_table = 'testo_item'

 class License(models.Model):
 name = models.PositiveIntegerField(db_index=True)

 class Meta:
 db_table = 'testo_license'
 }}}

 An important point to note is that I'm forcing InnoDB in my settings.py
 (which is the difference between this failing and not):
 {{{
 DATABASES = {
 'default': {
 ...
 'OPTIONS': {'init_command': 'SET storage_engine=InnoDB'},
 },
 }
 }}}

 At that point running sqlall will show you the order the commands are
 executed:

 {{{
 $ ./manage.py sqlall testo
 BEGIN;
 CREATE TABLE `testo_item` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `license_id` integer UNSIGNED
 )
 ;
 CREATE TABLE `testo_license` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `name` integer UNSIGNED
 )
 ;
 ALTER TABLE `testo_item` ADD CONSTRAINT `license_id_refs_name_a4fa988`
 FOREIGN KEY (`license_id`) REFERENCES `testo_license` (`name`);
 CREATE INDEX `testo_item_license_id` ON `testo_item` (`license_id`);
 CREATE INDEX `testo_license_name` ON `testo_license` (`name`);
 COMMIT;
 }}}

 Note that it's trying to add the foreign key before it creates the
 indexes.  Copying and pasting the above output will work fine, unless your
 default table type is InnoDB (or you can modify the CREATE TABLE
 statements and add ENGINE=InnoDB).

-- 
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] #13602: path for fix hardcode 'django_language'

[Django]

#13602: path for  fix  hardcode 'django_language'
---+
  Reporter:  ablis | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Internationalization  |   Version:  1.2
 
Resolution:  invalid   |  Keywords:  
LANGUAGE_COOKIE_NAME
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

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

Comment:

 Replying to [comment:2 ablis]:
 > code like that:
 > if hasattr(request, 'session'):
 > lang_code = request.session.get('django_language', None)
 > will not work. Because it's absolutely hardcode...  And your admin
 language will not be changed...

 Have you actually tried setting LANGUAGE_COOKIE_NAME and seen something
 break?

 I don't think you read or understood my first response.

 By default, Django uses the session to store your language preference. If
 contrib.sessions is not installed, it falls back to using a cookie. The
 two systems are entirely separate, and the cookie system is only used if
 you don't have sessions available.

 In the case of using the session, the session key name is hard-coded to
 "django_language." In the case of using the cookie, the cookie name is the
 value of LANGUAGE_COOKIE_NAME. A cookie name is visible to the site user,
 so there are valid use-cases for wanting to change it. A session key name
 is server-side-only, so there's no need to change it.

 If you think that the session key name should _also_ be configurable with
 a setting, that would be a separate setting, and you would need to bring
 that up as a feature request on the django-developers mailing list, with a
 use-case that justifies the need.

 Having LANGUAGE_COOKIE_NAME double also as a session key name, as your
 patch does, makes no sense: the name of the setting clearly indicates that
 it is a _cookie_ name.

 Please don't reopen this ticket again unless you can provide step-by-step
 instructions for how to reproduce an actual observable problem.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13605: Storage.listdir() missing from the reference page

[Django]

#13605: Storage.listdir() missing from the reference page
+---
 Reporter:  kopernikus  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.2   
 Keywords:  custom storage  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 http://docs.djangoproject.com/en/1.2/howto/custom-file-storage/ mentions
 Storage.listdir() as a required part of the interface but the linked
 reference page http://docs.djangoproject.com/en/1.2/ref/files/storage
 /#ref-files-storage lacks this method (and any description thereof ;))

 On a related note: It would be nice if either of those pages would give
 some hints (or link to) how to USE the custom storage. Do one have to make
 an instance and pass it to every field? Can this go into settings.py or
 Meta?

 thanks
  Paul

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

[Changeset] r13303 - django/tags/releases

[noreply]

Author: ubernostrum
Date: 2010-05-24 14:16:27 -0500 (Mon, 24 May 2010)
New Revision: 13303

Added:
   django/tags/releases/1.2.1/
Log:
Tag 1.2.1

Copied: django/tags/releases/1.2.1 (from rev 13302, django/trunk)

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

[Changeset] r13302 - in django/trunk: . django

[noreply]

Author: ubernostrum
Date: 2010-05-24 14:10:30 -0500 (Mon, 24 May 2010)
New Revision: 13302

Modified:
   django/trunk/django/__init__.py
   django/trunk/setup.py
Log:
Bump to 1.2.1.

Modified: django/trunk/django/__init__.py
===
--- django/trunk/django/__init__.py 2010-05-23 10:38:23 UTC (rev 13301)
+++ django/trunk/django/__init__.py 2010-05-24 19:10:30 UTC (rev 13302)
@@ -1,4 +1,4 @@
-VERSION = (1, 2, 1, 'alpha', 0)
+VERSION = (1, 2, 1, 'final', 0)
 
 def get_version():
 version = '%s.%s' % (VERSION[0], VERSION[1])

Modified: django/trunk/setup.py
===
--- django/trunk/setup.py   2010-05-23 10:38:23 UTC (rev 13301)
+++ django/trunk/setup.py   2010-05-24 19:10:30 UTC (rev 13302)
@@ -77,7 +77,7 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
-download_url = 
'http://media.djangoproject.com/releases/1.2/Django-1.2.tar.gz',
+download_url = 
'http://media.djangoproject.com/releases/1.2/Django-1.2.1.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
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] #13603: module_has_submodule fails when package is of type module

[Django]

#13603: module_has_submodule fails when package is of type module
+---
  Reporter:  eruq...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by carljm):

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

Comment:

 Looks like this has to do with putting a module in INSTALLED_APPS. Which
 doesn't make any sense to do, but I can confirm that in 1.1 it silently
 does nothing, whereas in 1.2 it blows up with that traceback.

-- 
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] #13604: AssertRedirects test method tests the status code of initial response instead of the last redirect

[Django]

#13604: AssertRedirects test method tests the status code of initial response
instead of the last redirect
---+
 Reporter:  jukvalim   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.2   
 Keywords:  assertRedirects|   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In assertRedirects method of TestCase, the named parameter
 "target_status_code" should, according to the documentation, test the
 status code of the final point of the redirect chain. It is compared to
 the status code of the first redirecting response instead.

 This is how the code is:
 {{{
 url, status_code = response.redirect_chain[-1]

 self.assertEqual(response.status_code, target_status_code,
 msg_prefix + "Response didn't redirect as expected: Final"
 " Response code was %d (expected %d)" %
 (response.status_code, target_status_code))
 }}}

 Unless I've misunderstood something, the last line there should use
 "status_code" instead of "response.status_code".

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13602: path for fix hardcode 'django_language'

[Django]

#13602: path for  fix  hardcode 'django_language'
---+
  Reporter:  ablis | Owner:  nobody 
 
Status:  reopened  | Milestone: 
 
 Component:  Internationalization  |   Version:  1.2
 
Resolution:|  Keywords:  
LANGUAGE_COOKIE_NAME
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by ablis):

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

Comment:

 I'm sorry, do you like hardcode?
 request.session['django_language'] and
 request.session[settings.LANGUAGE_COOKIE_NAME] is equivalent,
 but, for example, if you make in your settings.LANGUAGE_COOKIE_NAME =
 "site_language"?
 code like that:
 if hasattr(request, 'session'):
 lang_code = request.session.get('django_language', None)
 will not work. Because it's absolutely hardcode...  And your admin
 language will not be changed...

-- 
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] #13603: module_has_submodule fails when package is of type module

[Django]

#13603: module_has_submodule fails when package is of type module
---+
 Reporter:  eruq...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 module_has_submodule in utils/module_loading.py fails if the package is a
 module:

 {{{

 Traceback (most recent call last):
   File "/usr/local/lib/python2.5/site-packages/flup/server/fcgi_base.py",
 line 574, in run
 protocolStatus, appStatus = self.server.handler(self)
   File "/usr/local/lib/python2.5/site-packages/flup/server/fcgi_base.py",
 line 1159, in handler
 result = self.application(environ, start_response)
   File "/usr/local/lib/python2.5/site-
 packages/django/core/handlers/wsgi.py", line 241, in __call__
 response = self.get_response(request)
   File "/usr/local/lib/python2.5/site-
 packages/django/core/handlers/base.py", line 142, in get_response
 return self.handle_uncaught_exception(request, resolver, exc_info)
   File "/usr/local/lib/python2.5/site-
 packages/django/core/handlers/base.py", line 177, in
 handle_uncaught_exception
 if resolver.urlconf_module is None:
   File "/usr/local/lib/python2.5/site-
 packages/django/core/urlresolvers.py", line 238, in _get_urlconf_module
 self._urlconf_module = import_module(self.urlconf_name)
   File "/usr/local/lib/python2.5/site-packages/django/utils/importlib.py",
 line 35, in import_module
 __import__(name)
   File "/var/kunden/webs/ef134/dja/urls.py", line 9, in 
 admin.autodiscover()
   File "/usr/local/lib/python2.5/site-
 packages/django/contrib/admin/__init__.py", line 35, in autodiscover
 if module_has_submodule(mod, 'admin'):
   File "/usr/local/lib/python2.5/site-
 packages/django/utils/module_loading.py", line 14, in module_has_submodule
 for entry in package.__path__:  # No __path__, then not a package.
 AttributeError: 'module' object has no attribute '__path__'
 }}}


 Without any deeper understanding of the issue I "patched" the problem by
 adding:


 {{{
 if not hasattr(package, '__path__'):
 return False
 }}}

 right before the for loop.
 This may or may not be the best idea but it did end the downtime.


 (This is 1.2.0 final.)

-- 
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] #13598: Missing documentation regarding which Form fields may apply to which Model fields in ModelForm

[Django]

#13598: Missing documentation regarding which Form fields may apply to which 
Model
fields in ModelForm
-+--
  Reporter:  jonathan_livni  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Uncategorized   |   Version:  1.2   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by ubernostrum):

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

Comment:

 Django doesn't restrict the form field types you can use.

-- 
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] #13602: path for fix hardcode 'django_language'

[Django]

#13602: path for  fix  hardcode 'django_language'
---+
  Reporter:  ablis | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Internationalization  |   Version:  1.2
 
Resolution:  invalid   |  Keywords:  
LANGUAGE_COOKIE_NAME
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

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

Comment:

 I think you are confusing the _cookie_ name with the _session_ key name.
 LANGUAGE_COOKIE_NAME is correctly used when setting or getting the actual
 cookie. The session key name is hardcoded to django_language; but changing
 LANGUAGE_COOKIE_NAME will not affect that, and should not cause any
 problems with language in the admin.

 If you are seeing a problem when changing LANGUAGE_COOKIE_NAME, please
 post more detailed duplication instructions.

-- 
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] #13602: path for fix hardcode 'django_language'

[Django]

#13602: path for  fix  hardcode 'django_language'
--+-
 Reporter:  ablis |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Internationalization  | Version:  1.2   
 Keywords:  LANGUAGE_COOKIE_NAME  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 django/utils/translation/trans_real.py and django/views/i18n.py
 b/django/views/i18n.py have some hardcode session['django_language'].
 It will be some problem with language in admin if change
 settings.LANGUAGE_COOKIE_NAME. I attached path for fix 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] #8901: Django's guessed postgresql sequence name is incorrect if the resulting sequence name is longer than max_identifier_length

[Django]

#8901: Django's guessed postgresql sequence name is incorrect if the resulting
sequence name is longer than max_identifier_length
---+
  Reporter:  a...@zuerchertech.com | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  postgresql
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by Skaffen):

 I've had a go at a patch myself to fix the issue and have included some
 tests (I wasn't sure where to put them, so apologies if I've not added
 them into the best place). I've not submitted any code for django before
 so apologies for any newbie errors :). I figure the tests ought to behave
 on any database back-end assuming the back-end doesn't have any issues
 with auto field sequences on long model names or with long pk fields, so I
 haven't made them run only on postgres. I haven't included a test for the
 fix to sequence_reset_sql since there is no existing test to cover that
 which I could see in the test suites and the command doesn't run the sql
 it just displays it. I have tested the output by hand tho' to make sure
 it's valid - I guess the only way to do a unit test is either to verify
 the sql put out is what's expected or else actually try running the sql
 (if there is any for the back-end) - perhaps someone else could do that if
 it's necessary (or is a by-eye or by-hand check sufficient for that one)?

-- 
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] #11800: Remove extra metadata from QuerySet API

[Django]

#11800: Remove extra metadata from QuerySet API
+---
  Reporter:  timo   | Owner:  timo
Status:  assigned   | Milestone:  
 Component:  Documentation  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Ready for checkin  | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  1 => 0
  * summary:  Add metadata to QuerySet API => Remove extra metadata from
  QuerySet API
  * stage:  Accepted => Ready for checkin

Comment:

 modifying patch to remove extra metadata after additions in #12997

-- 
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] #8901: Django's guessed postgresql sequence name is incorrect if the resulting sequence name is longer than max_identifier_length

[Django]

#8901: Django's guessed postgresql sequence name is incorrect if the resulting
sequence name is longer than max_identifier_length
---+
  Reporter:  a...@zuerchertech.com | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  postgresql
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by Skaffen):

 Note that pg_get_serial_sequence doesn't exist prior to postgres version 8
 - I'm not sure what version of postgresql Django is supposed to support (a
 quick scout through the docs didn't really help). My guess, since I can
 only see references to differences in different version 8 minor releases,
 is that it's only been used/tested against version 8. Since version 8 was
 released in 2005 hopefully everyone who is using something as modern as
 Django 1.x is also on a version 8 of postgres :).

-- 
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] #12002: Models inherited from multiple Models

[Django]

#12002: Models inherited from multiple Models
---+
  Reporter:  vlastimil.z...@nic.cz | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by vzima):

 Another problem have been found with !ManyToManyField for Models with
 multiple parents:

 when deleting objects with multiple parent (e.g. Restaurant) objects
 related via many-to-many relationship are deleted twice - once for each
 primary key of parent object (e.g. Staff with pk equal to
 Restaurant.place_ptr_id and Staff with pk equal to
 Restaurant.staff_ptr_id). That breaks connections which should not be
 removed.

 For Restaurant with place_ptr_id = 1 and staff_ptr_id = 2 django generates
 following SQLs:
 {{{
 #!sql
 ...
 -- one that is not correct !
 DELETE FROM "app_staff_users" WHERE "staff_id" IN (1)
 -- and one that is correct
 DELETE FROM "app_staff_users" WHERE "staff_id" IN (2)
 ...
 }}}

 Error is generated in [django/db/models/sql/subqueries.py] on line 69,
 where pk_list is given through instead of generating correct primary keys
 that are involved in relation.

 I append diff that solves this issue and regenerates primary keys before
 given forward.

-- 
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] #13601: Django Admin Page not found

[Django]

#13601: Django Admin Page not found
---+
  Reporter:  morfeokmg | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  django.contrib.admin  |   Version:  1.1
Resolution:  invalid   |  Keywords:  ^admin/
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 Trac is for reporting bugs in Django, not support questions. Please ask
 questions like this in django-users group or on #django IRC. You have
 commented out the django.root option your config needs, which leads me to
 think you ran into some other problem when that was properly set. If so
 please follow up on one of the user support channels, not here.
 Alternatively you might consider using mod_wsgi instead of mod_python;
 mod_wsgi is a much better alternative, and easier to configure properly.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #8901: Django's guessed postgresql sequence name is incorrect if the resulting sequence name is longer than max_identifier_length

[Django]

#8901: Django's guessed postgresql sequence name is incorrect if the resulting
sequence name is longer than max_identifier_length
---+
  Reporter:  a...@zuerchertech.com | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  postgresql
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by Skaffen):

 BTW - having looked at the postgresql-get-sequence-name.diff patch I
 notice that it does a query in a function called get_sequence_name to get
 the sequence name which it then shovels into the call to select CURRVAL,
 which doesn't seem ideal. Instead it would be better to rework things
 slightly to just inline the call to pg_get_serial_sequence, e.g.:
 SELECT CURRVAL(pg_get_serial_sequence('tablename','id'));

-- 
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] #8901: Django's guessed postgresql sequence name is incorrect if the resulting sequence name is longer than max_identifier_length

[Django]

#8901: Django's guessed postgresql sequence name is incorrect if the resulting
sequence name is longer than max_identifier_length
---+
  Reporter:  a...@zuerchertech.com | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:  postgresql
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by Skaffen):

 Just to add a note to say that I'm now hitting this problem in an
 application after upgrading to Django 1.2 from Django 1.1.

 The reason I've started hitting it after migration is that
 ManyRelatedManager._add_items has changed how it works. Looking at the
 code it used to do the inserts itself into the m2m table and didn't care
 about the id column values were for those new entries so it never called
 last_insert_id. In Django 1.2 it looks like it uses a model save to create
 those entries and that will call last_insert_id. So if the length of your
 app name, model name and m2m field name combined plus the suffix of
 "_id_seq" are greater than 63 characters you will get an error.

 So if anyone using postgresql and django are getting an error of 'relation
 "..." does not exist' related to a SELECT CURRVAL when saving a model with
 m2m relationships after upgrading to Django 1.2, they've probably now hit
 this issue too. #

 I guess there's more chance people will hit this bug now as there's a
 greater chance of model name + m2m field name being long enough to trigger
 this (previously it would have only affected people who have defined very
 long model names?).

-- 
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] #7048: Support clearing FileFields with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  brosner
Status:  assigned  | Milestone: 
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Changes (by danfairs):

 * cc: dan.fa...@gmail.com (added)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13601: Django Admin Page not found

[Django]

#13601: Django Admin Page not found
--+-
 Reporter:  morfeokmg |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:  ^admin/   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hi, i configure my django install with Oracle and Apache 2.2, activate
 admin option but fail, error:



 {{{
 Page not found (404)
 Request Method: GET
 Request URL:http://srvlnx01.servehttp.com/linuxFriend/

 Using the URLconf defined in linuxFriend.urls, Django tried these URL
 patterns, in this order:

1. ^admin/

 The current URL, linuxFriend/, didn't match any of these.

 You're seeing this error because you have DEBUG = True in your Django
 settings file. Change that to False, and Django will display a standard
 404 page.

 }}}

 My settings :


 {{{
 ...
 ROOT_URLCONF = 'linuxFriend.urls'

 TEMPLATE_DIRS = (
 # Put strings here, like "/home/html/django_templates" or
 "C:/www/django/templates".
 # Always use forward slashes, even on Windows.
 # Don't forget to use absolute paths, not relative paths.
 )

 INSTALLED_APPS = (
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 ...
 }}}

 and my file urls.py


 {{{
 from django.conf.urls.defaults import *

 # Uncomment the next two lines to enable the admin:
 from django.contrib import admin
 admin.autodiscover()

 urlpatterns = patterns('',
 # Example:
 # (r'^linuxFriend/', include('linuxFriend.foo.urls')),

 # Uncomment the admin/doc line below and add
 'django.contrib.admindocs'
 # to INSTALLED_APPS to enable admin documentation:
 # (r'^admin/doc/', include('django.contrib.admindocs.urls')),

 # Uncomment the next line to enable the admin:
 (r'^admin/', include(admin.site.urls)),

 }}}

 I have modified files:
/etc/apache2/httpd.conf.local
Content:

 {{{
 
 SetHandler python-program
 PythonHandler django.core.handlers.modpython
 SetEnv DJANGO_SETTINGS_MODULE linuxFriend.settings
 #PythonOption django.root /linuxFriend
 PythonPath "['/srv/www/htdocs']+ sys.path"
 PythonDebug On
 
 }}}

 and file /etc/sysconfig/apache2 add next lines:

 {{{
 #APACHE_CONF_INCLUDE_FILES=""
 APACHE_CONF_INCLUDE_FILES="/etc/apache2/httpd.conf.local"
 }}}

 help me, pls.
 Tanks!.

-- 
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] #13588: removing admin.root as per deprecation policy

[Django]

#13588: removing admin.root as per deprecation policy
---+
  Reporter:  apollo13  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by apollo13):

 fixed to missing current_app hints

-- 
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] #13588: removing admin.root as per deprecation policy

[Django]

#13588: removing admin.root as per deprecation policy
---+
  Reporter:  apollo13  | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by apollo13):

 Ok, I updated the patch now. I can't see why this patch would need tests
 as all of the behaviour is tested already (just relative vs absolute paths
 now, which is fixed in the tests).

-- 
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] #13600: OverflowError not caught in django.views.static.serve

[Django]

#13600: OverflowError not caught in django.views.static.serve
+---
  Reporter:  KostikVento| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Old description:

> I noticed that sometimes I get an "OverflowError: mktime argument out of
> range" error in django.views.static.serve, when a request is made with a
> strange date, say, request.META contents something like
> {'HTTP_IF_MODIFIED_SINCE': 'Mon, 28 May 3121 28:25:26 GMT'}.
>
> Python docs say on this that the exceptions raised in mktime are either
> ValueError (if caught in Python layer) or OverflowError (if caught in C
> layer).
>
> I suppose it could be fixed with replacing the third endmost line in
> django.views.static.was_modified_since from actual
>
> except (AttributeError, ValueError):
>
> to
>
> except (AttributeError, ValueError, OverflowError):
>
> Probably, there has been some reason not to catch OverflowErrors, then
> sorry.

New description:

 I noticed that sometimes I get an "OverflowError: mktime argument out of
 range" error in django.views.static.serve, when a request is made with a
 strange date, say, request.META contents something like
 {'HTTP_IF_MODIFIED_SINCE': 'Mon, 28 May 3121 28:25:26 GMT'}.

 Python docs say on this that the exceptions raised in mktime are either
 ValueError (if caught in Python layer) or OverflowError (if caught in C
 layer).

 I suppose it could be fixed with replacing the third endmost line in
 django.views.static.was_modified_since from actual
 {{{
 except (AttributeError, ValueError):
 }}}
 to
 {{{
 except (AttributeError, ValueError, OverflowError):
 }}}
 Probably, there has been some reason not to catch OverflowErrors, then
 sorry.

-- 
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] #13600: OverflowError not caught in django.views.static.serve

[Django]

#13600: OverflowError not caught in django.views.static.serve
---+
 Reporter:  KostikVento|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I noticed that sometimes I get an "OverflowError: mktime argument out of
 range" error in django.views.static.serve, when a request is made with a
 strange date, say, request.META contents something like
 {'HTTP_IF_MODIFIED_SINCE': 'Mon, 28 May 3121 28:25:26 GMT'}.

 Python docs say on this that the exceptions raised in mktime are either
 ValueError (if caught in Python layer) or OverflowError (if caught in C
 layer).

 I suppose it could be fixed with replacing the third endmost line in
 django.views.static.was_modified_since from actual

 except (AttributeError, ValueError):

 to

 except (AttributeError, ValueError, OverflowError):

 Probably, there has been some reason not to catch OverflowErrors, then
 sorry.

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