[Django] #12036: GIS layermapping utility fails to import linestrings

2009-10-14 Thread Django
#12036: GIS layermapping utility fails to import linestrings
+---
 Reporter:  elpaso66|   Owner:  nobody
   Status:  new |   Milestone:
Component:  GIS | Version:  1.1   
 Keywords:  gis import  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 It seems like there is an error in type comparison around line 288,
 objects gtype and ltype are tested for equality while probably their
 string values should be tested instead.

 File: trunk/django/contrib/gis/utils/layermapping.py

 The patch below should fix this issue and give a more complete error
 message.

 {{{
 @@ -288,9 +288,10 @@
  raise LayerMapError('Invalid mapping for
 GeometryField "%s".' % field_name)

  # Making sure that the OGR Layer's Geometry is
 compatible.
 +
  ltype = self.layer.geom_type
 -if not (gtype == ltype or self.make_multi(ltype,
 model_field)):
 -raise LayerMapError('Invalid mapping geometry; model
 has %s, feature has %s.' % (fld_name, gtype))
 +if not (str(gtype) == str(ltype) or
 self.make_multi(ltype, model_field)):
 +raise LayerMapError('Invalid mapping geometry; model
 has %s, feature has %s instead of %s.' % (fld_name, gtype,  ltype))

 }}}

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



[Django] #12035: admin docs field dictionary miss GIS type informations

2009-10-14 Thread Django
#12035: admin docs field dictionary miss GIS type informations
---+
 Reporter:  elpaso66   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  GIS| Version:  1.1   
 Keywords:  gis admindocs  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 This result in an error while browsing admin docs:




 {{{
 KeyError at /admin/doc/models/risorse.poi/

 'PointField'

 Request Method: GET
 Request URL:http://127.0.0.1:8000/admin/doc/models/risorse.poi/
 Exception Type: KeyError
 Exception Value:

 'PointField'

 Exception Location: /trunk/django/contrib/admindocs/views.py in
 get_readable_field_data_type, line 369
 }}}

 This can be easily solved adding



 {{{
 Index: views.py
 ===
 --- views.py(revisione 11602)
 +++ views.py(copia locale)
 @@ -359,6 +359,14 @@
  'URLField'  : _('URL'),
  'USStateField'  : _('U.S. state (two uppercase
 letters)'),
  'XMLField'  : _('XML text'),
 +'PointField': _('GIS Point'),
 +'LineStringField'   : _('GIS Line'),
 +'PolygonField'  : _('GIS Polygon'),
 +'MultiLineString'   : _('GIS Multiple Line'),
 +'MultiLinePoint': _('GIS Multiple Point'),
 +'MultiLinePolygon'  : _('GIS Multiple Polygon'),
 +'GeometryCollectionField'   : _('GIS Geometry Collection')
 +
  }

  def get_readable_field_data_type(field):

 }}}

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



Re: [Django] #12034: Deleting an model instance doesn't call the delete() method of related instances (even though they are removed).

2009-10-14 Thread Django
#12034: Deleting an model instance doesn't call the delete() method of related
instances (even though they are removed).
---+
  Reporter:  ilblackdragon | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

  * status:  new => closed
  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * summary:  Do not calling delete() method of models, when remove related
  objects => Deleting an model instance doesn't
  call the delete() method of related instances
  (even though they are removed).
  * needs_docs:  => 0
  * resolution:  => wontfix

Comment:

 The `delete()` methods of related instances are not called because it
 would be highly inefficient (every related model would have to be
 instanciated).

 If you want to ensure your pre/post delete actions are run, you should be
 using the `pre_delete` or `post_delete` signals.

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



Re: [Django] #11526: LDAP authentication backend

2009-10-14 Thread Django
#11526: LDAP authentication backend
-+--
  Reporter:  psagers | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:  ldap  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by psagers):

 Thanks for the report, ekohl. I haven't been able to reproduce it, but
 I'll take your word that it's possible to trigger. The only purpose of the
 isinstance checks was to catch the handful of users who will use an
 LDAPGroupType class instead of an instance. I wanted to provide a friendly
 configuration error in that case. That said, a known blocking bug is more
 compelling than a speculative configuration aid, so I took out the calls.

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



Re: [Django] #11639: Can't remove prepopulated fields from fieldset in ModelAdmin

2009-10-14 Thread Django
#11639: Can't remove prepopulated fields from fieldset in ModelAdmin
---+
  Reporter:  leanmeandonothingmachine  | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by leanmeandonothingmachine):

 I updated the patch so it applies against trunk.

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



Re: [Django] #7028: Better raw_id_fields feedback in newform-admins branch

2009-10-14 Thread Django
#7028: Better raw_id_fields feedback in newform-admins branch
---+
  Reporter:  Marcob   | Owner:  nobody 
  
Status:  new   | Milestone:  1.2
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  
raw-id-fields nfa-someday
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by marcob):

 mrts, I tried it with IE7 but I got dreaded "Error on page". Can't find
 where is the problem (I tried for at least on hour, sorry :-( IE is a pita
 to debug). Hope there is someone smarter than me.

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



[Django] #12034: Do not calling delete() method of models, when remove related objects

2009-10-14 Thread Django
#12034: Do not calling delete() method of models, when remove related objects
---+
 Reporter:  ilblackdragon  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Do not calling delete method of models, when remove related objects.

 Example:
 {{{
 from django.db import models

 class myModel1(models.Model):

 def delete(self):
 print "Delete myModel1 called"
 super(myModel1, self).delete()

 class myModel2(models.Model):
 m = models.ForeignKey(myModel1)

 def delete(self):
 print "Delete myModel2 called"
 super(myModel2, self).delete()

 >>> a = myModel1()
 >>> a.save()
 >>> b = myModel2(m = a)
 >>> b.save()
 ...
 >>> a.delete()
 Delete myModel1 called
 >>> myModel2.objects.all()
 []
 }}}
 Object of myModel2 class deleted, but method myModel2.delete not called.

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



[Changeset] r11624 - in django/branches/releases/1.1.X: . django/contrib/auth/tests django/core tests/regressiontests/context_processors tests/regressiontests/context_processors/fixtures tests/regress

2009-10-14 Thread noreply

Author: lukeplant
Date: 2009-10-14 13:14:19 -0500 (Wed, 14 Oct 2009)
New Revision: 11624

Added:
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/fixtures/
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/fixtures/context-processors-users.xml
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_access.html
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_messages.html
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_no_access.html
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_perms.html
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_test_access.html
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_user.html
Removed:
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/fixtures/context-processors-users.xml
Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/contrib/auth/tests/remote_user.py
   django/branches/releases/1.1.X/django/core/context_processors.py
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/tests.py
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/urls.py
   
django/branches/releases/1.1.X/tests/regressiontests/context_processors/views.py
Log:
[1.1.X] Fixed #6552, #12031 - Make django.core.context_processors.auth lazy to 
avoid "Vary: Cookie" 

Thanks to o...@iola.dk, Suor for the report

Backport of r11623 from trunk



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11596
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11596,11623

Modified: 
django/branches/releases/1.1.X/django/contrib/auth/tests/remote_user.py
===
--- django/branches/releases/1.1.X/django/contrib/auth/tests/remote_user.py 
2009-10-14 18:09:13 UTC (rev 11623)
+++ django/branches/releases/1.1.X/django/contrib/auth/tests/remote_user.py 
2009-10-14 18:14:19 UTC (rev 11624)
@@ -2,7 +2,7 @@
 
 from django.conf import settings
 from django.contrib.auth.backends import RemoteUserBackend
-from django.contrib.auth.models import AnonymousUser, User
+from django.contrib.auth.models import User
 from django.test import TestCase
 
 
@@ -30,15 +30,15 @@
 num_users = User.objects.count()
 
 response = self.client.get('/remote_user/')
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 response = self.client.get('/remote_user/', REMOTE_USER=None)
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 response = self.client.get('/remote_user/', REMOTE_USER='')
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 def test_unknown_user(self):
@@ -115,7 +115,7 @@
 def test_unknown_user(self):
 num_users = User.objects.count()
 response = self.client.get('/remote_user/', REMOTE_USER='newuser')
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 

Modified: django/branches/releases/1.1.X/django/core/context_processors.py
===
--- django/branches/releases/1.1.X/django/core/context_processors.py
2009-10-14 18:09:13 UTC (rev 11623)
+++ django/branches/releases/1.1.X/django/core/context_processors.py
2009-10-14 18:14:19 UTC (rev 11624)
@@ -8,7 +8,28 @@
 """
 
 from django.conf import settings
+from django.utils.functional import lazy, memoize, LazyObject
 
+class ContextLazyObject(LazyObject):
+"""
+A lazy object initialised from any function, useful for lazily
+adding things to the Context.
+
+Designed for compound objects of unknown type. For simple objects of known
+type, use django.utils.functional.lazy.
+"""
+def __init__(self, func):
+"""
+Pass in a callable that returns the actual value to be used
+"""
+self.__dict__['_setupfunc'] = func
+   

[Changeset] r11623 - in django/trunk: django/contrib/auth/tests django/core tests/regressiontests/context_processors tests/regressiontests/context_processors/fixtures tests/regressiontests/context_pro

2009-10-14 Thread noreply

Author: lukeplant
Date: 2009-10-14 13:09:13 -0500 (Wed, 14 Oct 2009)
New Revision: 11623

Added:
   django/trunk/tests/regressiontests/context_processors/fixtures/
   
django/trunk/tests/regressiontests/context_processors/fixtures/context-processors-users.xml
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_access.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_messages.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_no_access.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_perms.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_test_access.html
   
django/trunk/tests/regressiontests/context_processors/templates/context_processors/auth_attrs_user.html
Modified:
   django/trunk/django/contrib/auth/tests/remote_user.py
   django/trunk/django/core/context_processors.py
   django/trunk/tests/regressiontests/context_processors/tests.py
   django/trunk/tests/regressiontests/context_processors/urls.py
   django/trunk/tests/regressiontests/context_processors/views.py
Log:
Fixed #6552, #12031 - Make django.core.context_processors.auth lazy to avoid 
"Vary: Cookie"

Thanks to o...@iola.dk, Suor for the report



Modified: django/trunk/django/contrib/auth/tests/remote_user.py
===
--- django/trunk/django/contrib/auth/tests/remote_user.py   2009-10-14 
13:41:37 UTC (rev 11622)
+++ django/trunk/django/contrib/auth/tests/remote_user.py   2009-10-14 
18:09:13 UTC (rev 11623)
@@ -2,7 +2,7 @@
 
 from django.conf import settings
 from django.contrib.auth.backends import RemoteUserBackend
-from django.contrib.auth.models import AnonymousUser, User
+from django.contrib.auth.models import User
 from django.test import TestCase
 
 
@@ -30,15 +30,15 @@
 num_users = User.objects.count()
 
 response = self.client.get('/remote_user/')
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 response = self.client.get('/remote_user/', REMOTE_USER=None)
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 response = self.client.get('/remote_user/', REMOTE_USER='')
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 def test_unknown_user(self):
@@ -115,7 +115,7 @@
 def test_unknown_user(self):
 num_users = User.objects.count()
 response = self.client.get('/remote_user/', REMOTE_USER='newuser')
-self.assert_(isinstance(response.context['user'], AnonymousUser))
+self.assert_(response.context['user'].is_anonymous())
 self.assertEqual(User.objects.count(), num_users)
 
 

Modified: django/trunk/django/core/context_processors.py
===
--- django/trunk/django/core/context_processors.py  2009-10-14 13:41:37 UTC 
(rev 11622)
+++ django/trunk/django/core/context_processors.py  2009-10-14 18:09:13 UTC 
(rev 11623)
@@ -8,7 +8,28 @@
 """
 
 from django.conf import settings
+from django.utils.functional import lazy, memoize, LazyObject
 
+class ContextLazyObject(LazyObject):
+"""
+A lazy object initialised from any function, useful for lazily
+adding things to the Context.
+
+Designed for compound objects of unknown type. For simple objects of known
+type, use django.utils.functional.lazy.
+"""
+def __init__(self, func):
+"""
+Pass in a callable that returns the actual value to be used
+"""
+self.__dict__['_setupfunc'] = func
+# For some reason, we have to inline LazyObject.__init__ here to avoid
+# recursion
+self._wrapped = None
+
+def _setup(self):
+self._wrapped = self._setupfunc()
+
 def auth(request):
 """
 Returns context variables required by apps that use Django's authentication
@@ -17,15 +38,26 @@
 If there is no 'user' attribute in the request, uses AnonymousUser (from
 django.contrib.auth).
 """
-if hasattr(request, 'user'):
-user = request.user
-else:
-from django.contrib.auth.models import AnonymousUser
-user = AnonymousUser()
+# If we access request.user, request.session is accessed, which results in
+# 'Vary: Cookie' being sent in every request that uses this context
+# processor, which can easily be every request on a site if
+# TEMPLATE_CONTEXT_PROCESSORS has 

Re: [Django] #7028: Better raw_id_fields feedback in newform-admins branch

2009-10-14 Thread Django
#7028: Better raw_id_fields feedback in newform-admins branch
---+
  Reporter:  Marcob   | Owner:  nobody 
  
Status:  new   | Milestone:  1.2
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  
raw-id-fields nfa-someday
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by mrts):

 I'd be much obliged if someone cared to test the
 ticket7028-with_popup.patch in IE.

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



Re: [Django] #10995: Improve paginator to account for very large page_range's

2009-10-14 Thread Django
#10995: Improve paginator to account for very large page_range's
-+--
  Reporter:  swilly  | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by stavros):

 I'd like to +1 this. Perhaps one could pass an argument to page_range to
 specify how many pages they wanted returned in total, around the current
 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---



Re: [Django] #11526: LDAP authentication backend

2009-10-14 Thread Django
#11526: LDAP authentication backend
-+--
  Reporter:  psagers | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:  ldap  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by ekohl):

 According to http://www.canonical.org/~kragen/isinstance/ reload might
 cause this behaviour. It also makes a case against isinstance usage in
 python. In my downloaded copy I've removed the checks and that does solve
 the problem. The is_staff and is_superuser are properly mapped and groups
 are mirrored.

 Thank you for the work you've put into it and I'm hoping this will find
 its way to django.

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



Re: [Django] #8618: Many-to-many intermediary tables can't have multiple foreign keys to source/target models

2009-10-14 Thread Django
#8618: Many-to-many intermediary tables can't have multiple foreign keys to
source/target models
-+--
  Reporter:  coda| Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  m2m intermediary 
validation
 Stage:  Accepted| Has_patch:  0
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by emulbreh):

 Convention: Select the foreign key named `to.__name__.lower()`.

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



Re: [Django] #11526: LDAP authentication backend

2009-10-14 Thread Django
#11526: LDAP authentication backend
-+--
  Reporter:  psagers | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:  ldap  
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by ekohl):

 I'm having trouble with the isinstance checks. If I put the group type
 directly in config.py, there's no problem, but if I put it in
 local_settings.py which is imported by settings.py, the check fails and
 the exception is raised. When I print the object, it's
 {{{}}} and I
 can't figure out what I've done wrong.

 I'm running Python 2.6.4rc1 and Django 1.1.1-1ubuntu1 on Ubuntu Karmic
 (9.10).

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



Re: [Django] #12032: Signals receivers not called when the receiver is a closure

2009-10-14 Thread Django
#12032: Signals receivers not called when the receiver is a closure
-+--
  Reporter:  a...@zvuk.net   | Owner: 
Status:  closed  | Milestone:  1.2
 Component:  Core framework  |   Version:  SVN
Resolution:  invalid |  Keywords:  signals
 Stage:  Unreviewed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by dc):

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

Comment:

 That's not a bug, that's a feature.

 def connect(self, receiver, sender=None, weak=True, dispatch_uid=None)

 weak[[BR]]
 Whether to use weak references to the receiver By default,
 the[[BR]]
 module will attempt to use weak references to the
 receiver[[BR]]
 objects. If this parameter is false, then strong
 references will[[BR]]
 be used.

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



Re: [Django] #11959: In tutorial, admin is broken throughout most of part 3

2009-10-14 Thread Django
#11959: In tutorial, admin is broken throughout most of part 3
+---
  Reporter:  carljm | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution:  fixed  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by russellm):

 (In [11622]) [1.1.X] Fixed #11959 -- Updated the tutorial to ensure that
 the admin site continues to work after URLpatterns are introduced. Thanks
 to carljm for the report and draft patch.
 Backport of r11621 from trunk.

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



[Changeset] r11622 - django/branches/releases/1.1.X/docs/intro

2009-10-14 Thread noreply

Author: russellm
Date: 2009-10-14 08:41:37 -0500 (Wed, 14 Oct 2009)
New Revision: 11622

Modified:
   django/branches/releases/1.1.X/docs/intro/tutorial01.txt
   django/branches/releases/1.1.X/docs/intro/tutorial02.txt
   django/branches/releases/1.1.X/docs/intro/tutorial03.txt
   django/branches/releases/1.1.X/docs/intro/tutorial04.txt
Log:
[1.1.X] Fixed #11959 -- Updated the tutorial to ensure that the admin site 
continues to work after URLpatterns are introduced. Thanks to carljm for the 
report and draft patch.

Backport of r11621 from trunk.

Modified: django/branches/releases/1.1.X/docs/intro/tutorial01.txt
===
--- django/branches/releases/1.1.X/docs/intro/tutorial01.txt2009-10-14 
13:38:31 UTC (rev 11621)
+++ django/branches/releases/1.1.X/docs/intro/tutorial01.txt2009-10-14 
13:41:37 UTC (rev 11622)
@@ -281,6 +281,7 @@
 polls/
 __init__.py
 models.py
+tests.py
 views.py
 
 This directory structure will house the poll application.

Modified: django/branches/releases/1.1.X/docs/intro/tutorial02.txt
===
--- django/branches/releases/1.1.X/docs/intro/tutorial02.txt2009-10-14 
13:38:31 UTC (rev 11621)
+++ django/branches/releases/1.1.X/docs/intro/tutorial02.txt2009-10-14 
13:41:37 UTC (rev 11622)
@@ -34,11 +34,11 @@
 * Run ``python manage.py syncdb``. Since you have added a new application
   to :setting:`INSTALLED_APPS`, the database tables need to be updated.
 
-* Edit your ``mysite/urls.py`` file and uncomment the lines below the
-  "Uncomment the next two lines..." comment. This file is a URLconf;
-  we'll dig into URLconfs in the next tutorial. For now, all you need to
-  know is that it maps URL roots to applications. In the end, you should
-  have a ``urls.py`` file that looks like this:
+* Edit your ``mysite/urls.py`` file and uncomment the lines that reference
+  the admin -- there are three lines in total to uncomment. This file is a
+  URLconf; we'll dig into URLconfs in the next tutorial. For now, all you
+  need to know is that it maps URL roots to applications. In the end, you
+  should have a ``urls.py`` file that looks like this:
 
 .. versionchanged:: 1.1
 The method for adding admin urls has changed in Django 1.1.

Modified: django/branches/releases/1.1.X/docs/intro/tutorial03.txt
===
--- django/branches/releases/1.1.X/docs/intro/tutorial03.txt2009-10-14 
13:38:31 UTC (rev 11621)
+++ django/branches/releases/1.1.X/docs/intro/tutorial03.txt2009-10-14 
13:41:37 UTC (rev 11622)
@@ -171,16 +171,24 @@
 This is the simplest view possible. Go to "/polls/" in your browser, and you
 should see your text.
 
-Now add the following view. It's slightly different, because it takes an
-argument (which, remember, is passed in from whatever was captured by the
-regular expression in the URLconf)::
+Now lets add a few more views. These views are slightly different, because
+they take an argument (which, remember, is passed in from whatever was
+captured by the regular expression in the URLconf)::
 
 def detail(request, poll_id):
 return HttpResponse("You're looking at poll %s." % poll_id)
 
-Take a look in your browser, at "/polls/34/". It'll display whatever ID you
-provide in the URL.
+def results(request, poll_id):
+return HttpResponse("You're looking at the results of poll %s." % 
poll_id)
 
+def vote(request, poll_id):
+return HttpResponse("You're voting on poll %s." % poll_id)
+
+Take a look in your browser, at "/polls/34/". It'll run the `detail()` method
+and display whatever ID you provide in the URL. Try "/polls/34/results/" and
+"/polls/34/vote/" too -- these will display the placeholder results and voting
+pages.
+
 Write views that actually do something
 ==
 
@@ -467,10 +475,10 @@
 ``mysite/urls.py`` to remove the poll-specific URLs and insert an
 :func:`~django.conf.urls.defaults.include`::
 
-...
+# ...
 urlpatterns = patterns('',
 (r'^polls/', include('mysite.polls.urls')),
-...
+# ...
 
 :func:`~django.conf.urls.defaults.include`, simply, references another URLconf.
 Note that the regular expression doesn't have a ``$`` (end-of-string match

Modified: django/branches/releases/1.1.X/docs/intro/tutorial04.txt
===
--- django/branches/releases/1.1.X/docs/intro/tutorial04.txt2009-10-14 
13:38:31 UTC (rev 11621)
+++ django/branches/releases/1.1.X/docs/intro/tutorial04.txt2009-10-14 
13:41:37 UTC (rev 11622)
@@ -52,10 +52,11 @@
 
 (r'^(?P\d+)/vote/$', 'vote'),
 
-So let's create a ``vote()`` function in ``mysite/polls/views.py``::
+We also created a dummy implementation of the ``vote()`` function. Let's
+c

Re: [Django] #11959: In tutorial, admin is broken throughout most of part 3

2009-10-14 Thread Django
#11959: In tutorial, admin is broken throughout most of part 3
+---
  Reporter:  carljm | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution:  fixed  |  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:  => fixed
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 (In [11621]) Fixed #11959 -- Updated the tutorial to ensure that the admin
 site continues to work after URLpatterns are introduced. Thanks to carljm
 for the report and draft 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---



[Changeset] r11621 - django/trunk/docs/intro

2009-10-14 Thread noreply

Author: russellm
Date: 2009-10-14 08:38:31 -0500 (Wed, 14 Oct 2009)
New Revision: 11621

Modified:
   django/trunk/docs/intro/tutorial01.txt
   django/trunk/docs/intro/tutorial02.txt
   django/trunk/docs/intro/tutorial03.txt
   django/trunk/docs/intro/tutorial04.txt
Log:
Fixed #11959 -- Updated the tutorial to ensure that the admin site continues to 
work after URLpatterns are introduced. Thanks to carljm for the report and 
draft patch.

Modified: django/trunk/docs/intro/tutorial01.txt
===
--- django/trunk/docs/intro/tutorial01.txt  2009-10-12 16:57:01 UTC (rev 
11620)
+++ django/trunk/docs/intro/tutorial01.txt  2009-10-14 13:38:31 UTC (rev 
11621)
@@ -281,6 +281,7 @@
 polls/
 __init__.py
 models.py
+tests.py
 views.py
 
 This directory structure will house the poll application.

Modified: django/trunk/docs/intro/tutorial02.txt
===
--- django/trunk/docs/intro/tutorial02.txt  2009-10-12 16:57:01 UTC (rev 
11620)
+++ django/trunk/docs/intro/tutorial02.txt  2009-10-14 13:38:31 UTC (rev 
11621)
@@ -34,11 +34,11 @@
 * Run ``python manage.py syncdb``. Since you have added a new application
   to :setting:`INSTALLED_APPS`, the database tables need to be updated.
 
-* Edit your ``mysite/urls.py`` file and uncomment the lines below the
-  "Uncomment the next two lines..." comment. This file is a URLconf;
-  we'll dig into URLconfs in the next tutorial. For now, all you need to
-  know is that it maps URL roots to applications. In the end, you should
-  have a ``urls.py`` file that looks like this:
+* Edit your ``mysite/urls.py`` file and uncomment the lines that reference
+  the admin -- there are three lines in total to uncomment. This file is a
+  URLconf; we'll dig into URLconfs in the next tutorial. For now, all you
+  need to know is that it maps URL roots to applications. In the end, you
+  should have a ``urls.py`` file that looks like this:
 
 .. versionchanged:: 1.1
 The method for adding admin urls has changed in Django 1.1.

Modified: django/trunk/docs/intro/tutorial03.txt
===
--- django/trunk/docs/intro/tutorial03.txt  2009-10-12 16:57:01 UTC (rev 
11620)
+++ django/trunk/docs/intro/tutorial03.txt  2009-10-14 13:38:31 UTC (rev 
11621)
@@ -171,16 +171,24 @@
 This is the simplest view possible. Go to "/polls/" in your browser, and you
 should see your text.
 
-Now add the following view. It's slightly different, because it takes an
-argument (which, remember, is passed in from whatever was captured by the
-regular expression in the URLconf)::
+Now lets add a few more views. These views are slightly different, because
+they take an argument (which, remember, is passed in from whatever was
+captured by the regular expression in the URLconf)::
 
 def detail(request, poll_id):
 return HttpResponse("You're looking at poll %s." % poll_id)
 
-Take a look in your browser, at "/polls/34/". It'll display whatever ID you
-provide in the URL.
+def results(request, poll_id):
+return HttpResponse("You're looking at the results of poll %s." % 
poll_id)
 
+def vote(request, poll_id):
+return HttpResponse("You're voting on poll %s." % poll_id)
+
+Take a look in your browser, at "/polls/34/". It'll run the `detail()` method
+and display whatever ID you provide in the URL. Try "/polls/34/results/" and
+"/polls/34/vote/" too -- these will display the placeholder results and voting
+pages.
+
 Write views that actually do something
 ==
 
@@ -467,10 +475,10 @@
 ``mysite/urls.py`` to remove the poll-specific URLs and insert an
 :func:`~django.conf.urls.defaults.include`::
 
-...
+# ...
 urlpatterns = patterns('',
 (r'^polls/', include('mysite.polls.urls')),
-...
+# ...
 
 :func:`~django.conf.urls.defaults.include`, simply, references another URLconf.
 Note that the regular expression doesn't have a ``$`` (end-of-string match

Modified: django/trunk/docs/intro/tutorial04.txt
===
--- django/trunk/docs/intro/tutorial04.txt  2009-10-12 16:57:01 UTC (rev 
11620)
+++ django/trunk/docs/intro/tutorial04.txt  2009-10-14 13:38:31 UTC (rev 
11621)
@@ -52,10 +52,11 @@
 
 (r'^(?P\d+)/vote/$', 'vote'),
 
-So let's create a ``vote()`` function in ``mysite/polls/views.py``::
+We also created a dummy implementation of the ``vote()`` function. Let's
+create a real version. Add the following to ``mysite/polls/views.py``::
 
 from django.shortcuts import get_object_or_404, render_to_response
-from django.http import HttpResponseRedirect
+from django.http import HttpResponseRedirect, HttpResponse
 from django.core.urlresolvers import reverse
   

Re: [Django] #6552: django.core.context_processors.auth causes "Vary: Cookie" header no matter what

2009-10-14 Thread Django
#6552: django.core.context_processors.auth causes "Vary: Cookie" header no 
matter
what
-+--
  Reporter:  o...@iola.dk| Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  Authentication  |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by lukeplant):

 I realise part of this overlaps slightly with #4604.  But this is really a
 separate issue.

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



Re: [Django] #12032: Signals receivers not called when the receiver is a closure

2009-10-14 Thread Django
#12032: Signals receivers not called when the receiver is a closure
-+--
  Reporter:  a...@zvuk.net   | Owner: 
Status:  new | Milestone:  1.2
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords:  signals
 Stage:  Unreviewed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * owner:  anonymous =>
  * status:  assigned => new

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



Re: [Django] #6552: django.core.context_processors.auth causes "Vary: Cookie" header no matter what

2009-10-14 Thread Django
#6552: django.core.context_processors.auth causes "Vary: Cookie" header no 
matter
what
-+--
  Reporter:  o...@iola.dk| Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  Authentication  |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

  * owner:  => lukeplant
  * status:  new => assigned

Comment:

 I think by far the best way to fix this is to make the context processor
 return user/messages/perms lazily.  This is more tricky than it sounds,
 but I have a patch that I think works, with tests, I'll attach shortly.

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



Re: [Django] #10706: Incorrect error from manage.py sql when app fails to load

2009-10-14 Thread Django
#10706: Incorrect error from manage.py sql when app fails to load
--+-
  Reporter:  Glenn| Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by lawgon ):

 any fix for this should also fix #11494 which has been closed as a
 duplicate of this. The same error that is reported here will also cause
 syncdb to fail silently, neither creating an error message nor adding the
 new model

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



Re: [Django] #11463: Vietnamese translation

2009-10-14 Thread Django
#11463: Vietnamese translation
+---
  Reporter:  Erik Unger   | Owner:  nobody
Status:  new| Milestone:
 Component:  Translations   |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by bne):

 * cc: b...@isotoma.com (added)

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



Re: [Django] #6836: locale for vietnamese

2009-10-14 Thread Django
#6836: locale for vietnamese
---+
  Reporter:  anhle | Owner:  anhle  
Status:  closed| Milestone: 
 Component:  Translations  |   Version:  SVN
Resolution:  invalid   |  Keywords:  locale vi (vietnam)
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by bne):

 * cc: b...@isotoma.com (added)

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



Re: [Django] #8927: Make Request proxy the WSGI environ

2009-10-14 Thread Django
#8927: Make Request proxy the WSGI environ
+---
  Reporter:  simon  | Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Gustavo):

 Hi.

 I need to get this fixed so we can use Repoze software in the Django app
 we maintain at work. I already started working on it and wanted to you
 know so we won't duplicate efforts.

 Please feel free to assign this ticket to me if you want - I'll propose a
 patch once I'm done anyway.

 Cheers,

  - Gustavo.

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



Re: [Django] #3594: Translation problem in javascript

2009-10-14 Thread Django
#3594: Translation problem in javascript
---+
  Reporter:  karsu | Owner:  arkx
Status:  new   | Milestone:  
 Component:  Internationalization  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Comment (by arkx):

 msaelices, that most certainly fixes the current problem by removing that
 part of the catalog forming algorithm completely, but if I understand your
 patch correctly, in turn we lose the ability to let users select their
 fallback language. I believe it is very important that we don't break
 that, as it would be strange if only Javascript translations didn't allow
 you to change it from English. Maybe the test case should be expanded a
 little to show the problem I mean here.

 Also, didn't my earlier patch already fix this problem for you? At least
 for me it works already without the changes you did.

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



Re: [Django] #11010: Add a foundation for rowlevel permissions in Django

2009-10-14 Thread Django
#11010: Add a foundation for rowlevel permissions in Django
-+--
  Reporter:  apollo13| Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Comment (by cont...@roelkramer.nl):

 I made my own row level permission system based on this patch. It's still
 in a very early stage, but if needed I can share my findings.

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



[Django] #12033: ModelAdmin.search_fields throws exception when using @ for non mysql database

2009-10-14 Thread Django
#12033: ModelAdmin.search_fields throws exception when using @ for non mysql
database
---+
 Reporter:  hvdklauw   |   Owner:  
nobody
   Status:  new|   Milestone:   
 
Component:  django.contrib.admin   | Version:  1.1  
 
 Keywords:  search_fields, fulltext, mysql, sqlite, error  |   Stage:  
Unreviewed
Has_patch:  0  |  
---+
 So for the production environment I would really like to use the fulltext
 search capabilities the @ prefix offers, but for development we hardly use
 the search anyway. And most people will use sqlite anyway.

 Django throwing an exception when using the @ option for a non mysql
 backend makes it impossible to keep your code the same.

 I suggest when using @ for a non mysql backend django throws an error in
 the error log and the normal search is used.

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



Re: [Django] #12032: Signals receivers not called when the receiver is a closure

2009-10-14 Thread Django
#12032: Signals receivers not called when the receiver is a closure
-+--
  Reporter:  a...@zvuk.net   | Owner:  anonymous
Status:  assigned| Milestone:  1.2  
 Component:  Core framework  |   Version:  SVN  
Resolution:  |  Keywords:  signals  
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * owner:  nobody => anonymous
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

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



[Django] #12032: Signals receivers not called when the receiver is a closure

2009-10-14 Thread Django
#12032: Signals receivers not called when the receiver is a closure
+---
 Reporter:  a...@zvuk.net   |   Owner:  nobody
   Status:  new |   Milestone:  1.2   
Component:  Core framework  | Version:  SVN   
 Keywords:  signals |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 {{{
 >>> from django.db import models
 >>> def x():
 ... def y(sender, **kwargs):
 ... print 'y called'
 ... models.signals.post_init.connect(y, sender = User)
 ...
 >>> x()
 >>>
 >>> def z(sender, **kwargs):
 ... print 'z called'
 ...
 >>> models.signals.post_init.connect(z, sender = User)
 >>>
 >>> a = User()
 z called
 >>>
 }}}

 Expected result:

 {{{
 >>> a = User()
 y called
 z called
 >>>
 }}}

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



Re: [Django] #5685: [patch] Add ability to perform pre-runtime setup before executing code

2009-10-14 Thread Django
#5685: [patch] Add ability to perform pre-runtime setup before executing code
-+--
  Reporter:  __hawkeye__ | Owner: 
Status:  new | Milestone: 
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Accepted| Has_patch:  0  
Needs_docs:  1   |   Needs_tests:  1  
Needs_better_patch:  0   |  
-+--
Changes (by obeattie):

 * cc: oli...@obeattie.com (added)

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



Re: [Django] #12012: Integration with the Python standard library logging module

2009-10-14 Thread Django
#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Comment (by vsajip):

 As per [http://groups.google.com/group/django-
 developers/msg/90b81d9f927d0bf0 this thread on django-developers]

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