Re: [Django] #9389: Cannot specify extra arguments when deserializing.

[Django]

#9389: Cannot specify extra arguments when deserializing.
+---
  Reporter:  johnnyleitrim  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Serialization  |   Version:  1.0   
Resolution:  duplicate  |  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:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Duplicate of #5711

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

Re: [Django] #9395: auth docs inconsistency -- built-in forms are now oldforms

[Django]

#9395: auth docs inconsistency -- built-in forms are now oldforms
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
  
Status:  closed  | Milestone:   
   
 Component:  Documentation   |   Version:  1.0  
   
Resolution:  invalid |  Keywords:  auth built-in 
forms oldforms
 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:

 You don't say what the problem is you ran into when importing
 django.contrib.auth.forms.  If there is some problem here you need to
 spell it out more clearly.  But it sounds more like a user question that
 would be more appropriate on django-users than in a ticket.

 In Django 1.0, there are no more oldforms or newforms, there is just
 django.forms (which used to be newforms).  The Django book was released
 quite a while before Django 1.0 so its note is outdated.  So the
 conclusion you reached -- that these forms are oldforms -- is incorrect.
 I don't see any need for the doc to clarify what kind of forms they are,
 since there is only one forms package in Django 1.0.

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

[Django] #9395: auth docs inconsistency -- built-in forms are now oldforms

[Django]

#9395: auth docs inconsistency -- built-in forms are now oldforms
--+-
 Reporter:  [EMAIL PROTECTED]|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Documentation | Version:  1.0   
 Keywords:  auth built-in forms oldforms  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hi, from reading the latest docs on auth here:
 http://docs.djangoproject.com/en/dev/topics/auth/#built-in-forms

 I ran into a problem in importing:
 django.contrib.auth.forms

 At the djangobook v1.0, Ch 12:
 http://www.djangobook.com/en/1.0/chapter12/

 there is a note that explains that
 "django.contrib.auth.forms.UserCreationForm is, at the time of
 publication, an oldforms Form." This leads me to believe that all forms
 under django.contrib.auth.forms are now oldforms.

 Could the docs on auth be updated to reflect the current state of builtin
 auth forms in v1.0? If they are indeed oldforms, then you can just copy
 the note from the djangobook and list the forms that are oldforms.

 thanks!
 ivan.

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

Re: [Django] #8571: comment framework throws obscure exception in {% comment_form_target %}

[Django]

#8571: comment framework throws obscure exception in {% comment_form_target %}
--+-
  Reporter:  [EMAIL PROTECTED] | Owner:  nobody 
 
Status:  closed   | Milestone:  post-1.0

 Component:  django.contrib.comments  |   Version:  1.0 

Resolution:  worksforme   |  Keywords:  comment, 
comment_form_target
 Stage:  Unreviewed   | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

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

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

Comment:

 Nevermind. I had a new app without any code, but I had included the
 app.urls in root urls.py, which I guess Django was giving me this panicky
 exception when an complete other app was trying to use the comments urls
 declared in the same file.

 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-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9394: Querying a many-to-many intermediate model from a manager on a multi-table inherited model produces extraneous queries

[Django]

#9394: Querying a many-to-many intermediate model from a manager on a 
multi-table
inherited model produces extraneous queries
---+
  Reporter:  ikelly| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ikelly):

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

Comment:

 The occurrences of !ChineseRestaurant in the models should just be
 Restaurant.  Sorry about that.

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

[Django] #9394: Querying a many-to-many intermediate model from a manager on a multi-table inherited model produces extraneous queries

[Django]

#9394: Querying a many-to-many intermediate model from a manager on a 
multi-table
inherited model produces extraneous queries
--+-
 Reporter:  ikelly|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 With the following models:
 {{{
 class Place(models.Model):
 name = models.CharField(max_length=50)

 class Business(Place):
 owner = models.CharField(max_length=50)

 class Restaurant(Business):
 rating = models.IntegerField()

 class Chef(models.Model):
 name = models.CharField(max_length=50)
 restaurants = models.ManyToManyField(ChineseRestaurant,
 through='Employee')

 class Employee(models.Model):
 restaurant = models.ForeignKey(ChineseRestaurant)
 chef = models.ForeignKey(Chef)
 years_of_service = models.IntegerField()
 }}}
 we can do {{{some_restaurant.employee_set.all()}}}, which results in three
 queries.  The first two queries are just retrieving the attributes of the
 inherited Business and Place models, which is unnecessary since all that
 information already exists on the some_restaurant object.  Only one query
 should be needed.

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

[Changeset] r9233 - django/trunk/django/contrib/admin/templatetags

[noreply]

Author: kmtracey
Date: 2008-10-17 17:43:36 -0500 (Fri, 17 Oct 2008)
New Revision: 9233

Modified:
   django/trunk/django/contrib/admin/templatetags/log.py
Log:
Fixed #8110 -- Allow for AdminLogNode's render to be called more than once.


Modified: django/trunk/django/contrib/admin/templatetags/log.py
===
--- django/trunk/django/contrib/admin/templatetags/log.py   2008-10-13 
19:41:48 UTC (rev 9232)
+++ django/trunk/django/contrib/admin/templatetags/log.py   2008-10-17 
22:43:36 UTC (rev 9233)
@@ -14,9 +14,10 @@
 if self.user is None:
 context[self.varname] = 
LogEntry.objects.all().select_related('content_type', 'user')[:self.limit]
 else:
-if not self.user.isdigit():
-self.user = context[self.user].id
-context[self.varname] = 
LogEntry.objects.filter(user__id__exact=self.user).select_related('content_type',
 'user')[:self.limit]
+user_id = self.user
+if not user_id.isdigit():
+user_id = context[self.user].id
+context[self.varname] = 
LogEntry.objects.filter(user__id__exact=user_id).select_related('content_type', 
'user')[:self.limit]
 return ''
 
 class DoGetAdminLog:


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9392: Inherited model fields being duplicated in Forms

[Django]

#9392: Inherited model fields being duplicated in Forms
+---
  Reporter:  terpsquared| 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 terpsquared):

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

Comment:

 I thought that the problem might have been related to the _id suffix on
 the email_id field, but I got the same behavior with the fieldname
 "user_email" instead of "email_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-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9393: Overridden inherited model fields being duplicated in forms

[Django]

#9393: Overridden inherited model fields being duplicated in forms
+---
  Reporter:  terpsquared| 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 terpsquared):

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

Comment:

 I may have failed to specify that the duplicated field here has the same
 name in the parent and child models.

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

[Django] #9393: Overridden inherited model fields being duplicated in forms

[Django]

#9393: Overridden inherited model fields being duplicated in forms
---+
 Reporter:  terpsquared|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Likely related to (but distinct from) #9392, and possibly #9371.

 Given an inherited model of the form:

 {{{
 from django.db import models
 from django.contrib.auth.models import User, UserManager
 from django.utils.translation import ugettext_lazy as _
 from datetime import datetime


 class Customuser(User):
 username = models.CharField(_('customer id'), max_length=30,
 unique=True, help_text=_("Required. 30 characters or fewer. Alphanumeric
 characters only (letters, digits and underscores)."))
 email_id = models.EmailField(_('e-mail address'), blank=True,
 null=True, unique=True, db_index=True)

 def __unicode__(self):
 return u'%s' % self.username

 # Use UserManager to get the create_user method, etc.
 objects = UserManager()
 }}}

 A form specifying the inherited field "username" will display the username
 field twice during output. For example,

 {{{
 from django import forms
 from django.forms import ModelForm

 class CustomForm1(ModelForm):
 class Meta:
 model = Customuser
 fields = ('username')
 }}}

 will result in the following html output from the form:

 {{{
 Customer id:Required. 30 characters or fewer. Alphanumeric characters only (letters,
 digits and underscores).
 Name:
 }}}

 Notice that this is different from #9392.  In that case, the email_id
 field is distinct from the email field, but both are being displayed.  In
 this case, both the original field and the inherited field seem to be
 displayed.

 A solution to this would necessitate a design decision:  Only show the
 inherited field, provide a mechanism for specifying which field is
 intended, or throw an error would seem to be the best possible answers.

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

Re: [Django] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
---+
  Reporter:  adrian| Owner:  barbuza
   
Status:  reopened  | Milestone:  post-1.0   
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  nfa-someday 
nfa-changelist
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Changes (by Guilherme M. Gondim <[EMAIL PROTECTED]>):

 * cc: [EMAIL PROTECTED] (added)

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

[Django] #9391: Expose more admin objects in `django.contrib.gis.admin` for API consistency

[Django]

#9391: Expose more admin objects in `django.contrib.gis.admin` for API 
consistency
---+
 Reporter:  jbronn |   Owner:  jbronn
   Status:  new|   Milestone:  post-1.0  
Component:  GIS| Version:  1.0   
 Keywords:  gis admin  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 All of `django.contrib.admin`'s objects are not exposed in
 `django.contrib.gis.admin`.  At the least `ModelAdmin` and `AdminSite`
 should also be exposed; this will make consistent with other !GeoDjango
 modules (see `django.contrib.gis.db.models`).

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

[Django] #9390: select_related() documentation is incomplete

[Django]

#9390: select_related() documentation is incomplete
---+
 Reporter:  Tarken |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 According to the documentation here:
 http://docs.djangoproject.com/en/dev/ref/models/querysets/#id4 'depth' is
 the only possible argument to the select_related() function. There is no
 mention of the ability to specify which fields to select.

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

Re: [Django] #7587: Find out where the default admin/base_site.html is on your system (for: Tut 2, page 2)

[Django]

#7587: Find out where the default admin/base_site.html is on your system (for: 
Tut
2, page 2)
+---
  Reporter:  HenkPoley  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by johntynan):

 I believe this directory only contains symlinks to the files themselves.

 To find the actual base_site.html file, you'll want to find the path to
 the symlink as described above, cd into the directory containing the
 symlink to base_site.html, then use the command:

 ls base_site.html -l

 This will give you the path to the actual file.

 Then, you'll want to cd to this directory and, as root, copy the file to
 your working mysite/templates/admin directory:

 sudo cp base_site.html /home/username/.../mysite/templates/admin

 Then you'll want to cd into your working directory and change the
 ownership of the file:

 sudo chown username base_site.html

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

Re: [Django] #8094: Html button inside html link gives pipe error!!!

[Django]

#8094: Html button inside html link gives pipe error!!!
+---
  Reporter:  italomaia  | Owner:  nobody  
Status:  closed | Milestone:  1.0 beta
 Component:  Uncategorized  |   Version:  SVN 
Resolution:  worksforme |  Keywords:  error, html, strange
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by dfshtsehsdf):

 For what it's worth, I get a very similar error on OS X with Firefox 3. I
 first encountered the error trying to embed an image, created by a view,
 in my template.

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

Re: [Django] #9388: Year navigation in admin's date widgets' calendar

[Django]

#9388: Year navigation in admin's date widgets' calendar
---+
  Reporter:  framos| Owner:  versae  
Status:  assigned  | Milestone:  post-1.0
 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 versae):

  * status:  new => assigned
 * cc: [EMAIL PROTECTED] (removed)
 * cc: [EMAIL PROTECTED] (added)
  * needs_better_patch:  => 0
  * component:  Contrib apps => django.contrib.admin
  * needs_tests:  => 0
  * owner:  nobody => versae
  * needs_docs:  => 0
  * has_patch:  0 => 1

Comment:

 Patch added.
 If backwards compatibility is required, I can send a new patch with the
 proposal, it's done but I chose not to include it.

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

[Django] #9389: Cannot specify extra arguments when deserializing.

[Django]

#9389: Cannot specify extra arguments when deserializing.
---+
 Reporter:  johnnyleitrim  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Serialization  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I wrote my own custom serializer.  I can pass my Serializer parameters
 when I make a call to it:

 {{{ serializers.serialize("my_format", queryset, my_param = my_value) }}}

 I can get the value of my_param in my Serializer class.

 However, I cannot do the same when deserializing.  This is because the
 deserialize method in {{{ django.core.serializer.__init__.py}}} does not
 accept any extra parameters:

 {{{
 def deserialize(format, stream_or_string):
 """
 Deserialize a stream or a string. Returns an iterator that yields
 ``(obj,
 m2m_relation_dict)``, where ``obj`` is a instantiated -- but
 *unsaved* --
 object, and ``m2m_relation_dict`` is a dictionary of
 ``{m2m_field_name :
 list_of_related_objects}``.
 """
 d = get_deserializer(format)
 return d(stream_or_string)
 }}}

 I think that this should be changed to allow for optional parameters:

 {{{
 def deserialize(format, stream_or_string, **options):
 """
 Deserialize a stream or a string. Returns an iterator that yields
 ``(obj,
 m2m_relation_dict)``, where ``obj`` is a instantiated -- but
 *unsaved* --
 object, and ``m2m_relation_dict`` is a dictionary of
 ``{m2m_field_name :
 list_of_related_objects}``.
 """
 d = get_deserializer(format)
 return d(stream_or_string, **options)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
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 guettli):

 * cc: [EMAIL PROTECTED] (added)

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

[Django] #9388: Year navigation in admin's date widgets' calendar

[Django]

#9388: Year navigation in admin's date widgets' calendar
--+-
 Reporter:  framos|   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  Contrib apps  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 My colleague Javier de la Rosa has enhanced the calendar shown in admin's
 date fields to allow navigation through years, and not only through
 months. This requires changing calendar.js and DateTimeShortcuts.js.

 We have chosen not to maintain backwards compatibility because this should
 be a feature in Django 1.1, but it's easy to do if required.

 Javier de la Rosa will attach his patch later.

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

Re: [Django] #5863: list_display does not allow functions of referenced objects

[Django]

#5863: list_display does not allow functions of referenced objects
---+
  Reporter:  Beat Bolli <[EMAIL PROTECTED]>  | Owner:  nobody   
   
Status:  reopened  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  
list_display
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by pihentagy):

 Replying to [comment:12 kmtracey]:
 > Replying to [comment:11 pihentagy]:
 > > Consistency and DRY: so you shouldn't write boilerplate code. You
 shouldn't specify column name django alredy knows.
 >
 > I understand wanting to avoid boilerplate code but I'm missing how this
 is a common enough case to warrant inclusion and balance the additional
 complexity (both for users -- the list of things you can put in
 list_display is getting a bit long -- and code maintainers).  What's the
 common situation where user's would really like to see the value of a
 field in a related model instead of just the text representation of the
 related model?  I'm just not seeing that as a very common need, meaning
 when you need it if you have to write a little extra code it's no big
 deal.  It's not boilerplate if you only have to do it in rare situations.
 I'm looking for something a little more concrete as motivation than mom
 and apple pie goodness.

 If you have just 1 or 2 foreign keys, you have a lot of place, so it seems
 logical to display more interesting fields from a foreignkey. The unicode
 representation is ok, but it is just 1 column, you will find things
 quickly, if you have 2 or 3 fields from a foreign tabble (not to mention,
 you will be able to sort on that field for free!)

 For example m2m tables with additional fields doesn't contain interesting
 information on their own. Maybe you want to display more columns from one
 FK and sort on them...

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

Re: [Django] #8505: The installation instructions assume a pathname without a space in the directory names

[Django]

#8505: The installation instructions assume a pathname without a space in the
directory names
-+--
  Reporter:  jonathanberger  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Documentation   |   Version:  SVN   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jonathanberger):

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

Comment:

 This was fixed (although obviously not as a result 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-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2507: [patch] LDAPBackend in django/contrib/auth/backends.py

[Django]

#2507: [patch] LDAPBackend in django/contrib/auth/backends.py
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by EvilDMP):

 In order for this not to throw up an error:
 {{{
 Exception Value:
 'dict' object has no attribute 'LDAP_OPTIONS'
 Exception Location:
 /usr/lib/python2.5/site-packages/django/contrib/auth/ldapauth.py in
 authenticate, line 113
 }}}
 line 113 of ldapauth.py:
 {{{
 self.ldap.set_option(k, self.settings.LDAP_OPTIONS[k])
 }}}
 needs to be:
 {{{
 self.ldap.set_option(k, self.settings["LDAP_OPTIONS"][k])
 }}}
 I presume that other instances of that syntax need to be changed.

 Also, the syntax for settings.py that worked for me were:
 {{{
 import ldap
 LDAP_OPTIONS = 'ldap.OPT_X_TLS_DEMAND,1'
 }}}

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

Re: [Django] #2443: Add IntervalField to database models

[Django]

#2443: Add IntervalField to database models
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  Gulopine  
   
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  
IntervalField interval duration DurationField
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  1 |  
---+
Changes (by guettli):

 * cc: [EMAIL PROTECTED] (added)

Comment:

 Related: http://www.djangosnippets.org/snippets/1060/

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

Re: [Django] #9355: eol-style properties for commiters svn config file

[Django]

#9355: eol-style properties for commiters svn config file
+---
  Reporter:  Semmel | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Semmel):

 Err ... so what do they use then? I mean - it's an subversion repository
 after all. :)
 Anyway - if it is that way then we just have to live with it and fix it
 from time to time. Aight.

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

Re: [Django] #9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty

[Django]

#9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty
-+--
  Reporter:  adunar  | Owner:  nobody   
Status:  new | Milestone:  post-1.0 
 Component:  Core framework  |   Version:  1.0  
Resolution:  |  Keywords:  500 error mail_admins
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by adunar):

 In regards to documentation, I'm not sure what there is to document, or
 where to document it. The only functional difference is that instead of
 opening a connection to the SMTP server and then immediately closing it
 without sending anything, it just doesn't do anything at all.

 As far as unit tests, perhaps something like this?

 {{{
 #!python
 settings.ADMINS = []
 old_smtp_connection = django.core.mail.SMTPConnection
 django.core.mail.SMTPConnection = None # overwrite it with something that
 would fail if we tried to use it
 mail_admins('hi','there') # should fail if it actually tries to make an
 SMTP connection
 django.core.mail.SMTPConnection = old_smtp_connection # clean up
 }}}

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

Re: [Django] #9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty

[Django]

#9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty
-+--
  Reporter:  adunar  | Owner:  nobody   
Status:  new | Milestone:  post-1.0 
 Component:  Core framework  |   Version:  1.0  
Resolution:  |  Keywords:  500 error mail_admins
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Changes (by ubernostrum):

  * needs_better_patch:  => 1
  * stage:  Unreviewed => Accepted
  * component:  HTTP handling => Core framework
  * needs_tests:  => 0
  * needs_docs:  => 1

Comment:

 Seems like a good idea; this needs documentation, though (to explain the
 behavior when `ADMINS` and/or `MANAGERS` is empty), and potentially unit
 tests (though I'm not certain how you'd go about testing this behavior).

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

Re: [Django] #9379: possible error in tutorial 4

[Django]

#9379: possible error in tutorial 4
-+--
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Documentation   |   Version:  1.0   
Resolution:  duplicate   |  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:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Duplicate of #7709, #7660 and #7442. In the future, *please* search for
 existing tickets before filing new ones.

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