Re: django.contrib.auth 1.8 failed if user.pk not int

[Tim Graham]

Here's the commit and ticket:

https://github.com/django/django/commit/0f7f5bc9
https://code.djangoproject.com/ticket/24161

I think you'll probably have to fix this in your app, but if a change in 
Django will help, let me know. Possibly your user model needs a CharField 
for its primary key.

On Friday, October 9, 2015 at 5:06:59 PM UTC-4, Petr Bondarenko wrote:
>
> Hi,
>
> when migrating code from version 1.7 to 1.8 I have a problem.
> We do not use standard authentication through ModelBackend.
> Authentication takes place on a different server protocol OAuth2.
> For the User, using fake-model RemoteApiUser. In which the primary key is 
> *access_token*.
> Acces_token is written to the standard key 
> *django.contrib.auth.SESSION_KEY*.
> It is used in RemoteAuthenticationBackend as *user_id* in *get_user()*
>  function.
> This function generates a request to api-server  in which the token is 
> returned by the User.
> It is formed from the data object RemoteApiUser and return it.
>
> In version 1.7. everything worked fine, but when migrating to 1.8 there is 
> an error:
>
> Traceback (most recent call last):
> File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run
> self.result = application(self.environ, self.start_response)
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/staticfiles/handlers.py",
>  
> line 63, in __call__
> return self.application(environ, start_response)   
>
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/core/handlers/wsgi.py",
>  
> line 189, in __call__
> response = self.get_response(request)
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/core/handlers/base.py",
>  
> line 218, in get_response
> response = self.handle_uncaught_exception(request, resolver, 
> sys.exc_info())
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/core/handlers/base.py",
>  
> line 261, in handle_uncaught_exception
> return debug.technical_500_response(request, *exc_info)
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py", 
> line 97, in technical_500_response
> html = reporter.get_traceback_html()
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py", 
> line 383, in get_traceback_html
> c = Context(self.get_traceback_data(), use_l10n=False)
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py", 
> line 328, in get_traceback_data
> frames = self.get_traceback_frames()  
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py", 
> line 501, in get_traceback_frames
> 'vars': self.filter.get_traceback_frame_variables(self.request, 
> tb.tb_frame),
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py", 
> line 234, in get_traceback_frame_variables
> cleansed[name] = self.cleanse_special_types(request, value)   
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py", 
> line 189, in cleanse_special_types
> if isinstance(value, HttpRequest):
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/utils/functional.py",
>  
> line 225, in inner
> self._setup()
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/utils/functional.py",
>  
> line 365, in _setup
> self._wrapped = self._setupfunc()
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/middleware.py",
>  
> line 22, in 
> request.user = SimpleLazyObject(lambda: get_user(request))
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/middleware.py",
>  
> line 10, in get_user
> request._cached_user = auth.get_user(request)
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/__init__.py",
>  
> line 167, in get_user
> user_id = _get_user_session_key(request)
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/__init__.py",
>  
> line 59, in _get_user_session_key
> return get_user_model()._meta.pk.to_python(request.session[SESSION_KEY])
> File 
> "/root/django/envs/wallet/lib/python3.4/site-packages/django/db/models/fields/__init__.py",
>  
> line 969, in to_python
> params={'value': value},
> django.core.exceptions.ValidationError: ["Value 
> 'TBQqn1Cpz4aO1UNeDgKzmgvtW1ygTS' must be int."]
>
> For what purpose we have introduced such a restriction?
> Can I get around it without rewriting the whole authentication mechanism?
> As the authenctication server uses Django with oauth2_provider package.
>
> P.S. Sorry for bad English.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to 

Re: Upgrade path for Django 1.4.9 to Django 1.6.0

[Tim Graham]

The docs have some tips (but not much besides what James already offered): 
https://docs.djangoproject.com/en/dev/howto/upgrade-version/

On Friday, October 9, 2015 at 8:17:21 PM UTC-4, James Schneider wrote:
>
>
> > In the past when I have upgraded my Django Projects to a new version of 
> Django I have simply Google'd errors that my project produces and fixed 
> them one at a time and ran my unit tests and did the same.
> >
> > Is there a better path?
> >
> > So far I appear to be looking in all the wrong places.
>
> Start with the release notes for the next major version, and especially 
> check out the deprecation and backwards incompatible changes. 
>
> Upgrade one major version at a time. A version control system and 
> virtualenv are your friends in this case. Repeat as necessary.
>
> Your subject line indicates you want to jump from 1.4.X to 1.6.X. Note 
> that 1.6.X is no longer supported, so you'll need to continue on to at 
> least 1.7.X. Since you are on an LTS version now, I would recommend 
> updating to 1.8.X, which is the current LTS version.
>
> Based on the release notes and other announcements, the Django team will 
> be taking more care to have a direct upgrade path recommendation between 
> versions, and will support jumping from one LTS directly to the next. 
> Unfortunately, that isn't really in place for 1.4, but I'm sure plenty of 
> folks have done it and documented their stumbling blocks. 
>
> So, as long as you're keeping up with the announcements and release notes, 
> updating your code and tests us the logical next step. The prices should be 
> less painful in the future. I haven't personally experienced much pain 
> between versions, but plenty of folks have and may have better advice.
>
> -James
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/69ead042-dd19-4467-af87-da19cf0509f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Upgrade path for Django 1.4.9 to Django 1.6.0

[James Schneider]

> In the past when I have upgraded my Django Projects to a new version of
Django I have simply Google'd errors that my project produces and fixed
them one at a time and ran my unit tests and did the same.
>
> Is there a better path?
>
> So far I appear to be looking in all the wrong places.

Start with the release notes for the next major version, and especially
check out the deprecation and backwards incompatible changes.

Upgrade one major version at a time. A version control system and
virtualenv are your friends in this case. Repeat as necessary.

Your subject line indicates you want to jump from 1.4.X to 1.6.X. Note that
1.6.X is no longer supported, so you'll need to continue on to at least
1.7.X. Since you are on an LTS version now, I would recommend updating to
1.8.X, which is the current LTS version.

Based on the release notes and other announcements, the Django team will be
taking more care to have a direct upgrade path recommendation between
versions, and will support jumping from one LTS directly to the next.
Unfortunately, that isn't really in place for 1.4, but I'm sure plenty of
folks have done it and documented their stumbling blocks.

So, as long as you're keeping up with the announcements and release notes,
updating your code and tests us the logical next step. The prices should be
less painful in the future. I haven't personally experienced much pain
between versions, but plenty of folks have and may have better advice.

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciUYGiVLwJ9zoKJUWzAq5iOHTtbi0YTxUOaA%2Bw6KZaS%3DsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Upgrade path for Django 1.4.9 to Django 1.6.0

[Mark Engstrom]

In the past when I have upgraded my Django Projects to a new version of 
Django I have simply Google'd errors that my project produces and fixed 
them one at a time and ran my unit tests and did the same.

Is there a better path?

So far I appear to be looking in all the wrong places.

Thanks!

Mark

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/aef486bd-5c46-478f-bd59-41e1353ecbb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Don't run python manage.py syncdb

[Rafael E. Ferrero]

i think that u need to set 'myApp' in INSTALLED_APPS

something like:

> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'myApp'


--
Rafael E. Ferrero

2015-10-09 16:39 GMT-03:00 Faffafa Trtrtrtrt :

> I create question in
> http://stackoverflow.com/questions/32999054/dont-run-python-manage-py-syncdb.
> Any one can answer it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d1334ecc-3070-4968-b81f-ab1942841c8c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJJc_8UAL%2B%2BYSCNUwXJ4C_nJhwsmVrd5XYFfmJ8Wrk8p5AH_QA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

django.contrib.auth 1.8 failed if user.pk not int

[Petr V. Bondarenko]

Hi,

when migrating code from version 1.7 to 1.8 I have a problem.
We do not use standard authentication through ModelBackend.
Authentication takes place on a different server protocol OAuth2.
For the User, using fake-model RemoteApiUser. In which the primary key is
*access_token*.
Acces_token is written to the standard key *django.contrib.auth.SESSION_KEY*
.
It is used in RemoteAuthenticationBackend as *user_id* in *get_user()*
 function.
This function generates a request to api-server  in which the token is
returned by the User.
It is formed from the data object RemoteApiUser and return it.

In version 1.7. everything worked fine, but when migrating to 1.8 there is
an error:

Traceback (most recent call last):
File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/staticfiles/handlers.py",
line 63, in __call__
return self.application(environ, start_response)

File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/core/handlers/wsgi.py",
line 189, in __call__
response = self.get_response(request)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/core/handlers/base.py",
line 218, in get_response
response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/core/handlers/base.py",
line 261, in handle_uncaught_exception
return debug.technical_500_response(request, *exc_info)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py",
line 97, in technical_500_response
html = reporter.get_traceback_html()
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py",
line 383, in get_traceback_html
c = Context(self.get_traceback_data(), use_l10n=False)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py",
line 328, in get_traceback_data
frames = self.get_traceback_frames()
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py",
line 501, in get_traceback_frames
'vars': self.filter.get_traceback_frame_variables(self.request,
tb.tb_frame),
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py",
line 234, in get_traceback_frame_variables
cleansed[name] = self.cleanse_special_types(request, value)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/views/debug.py",
line 189, in cleanse_special_types
if isinstance(value, HttpRequest):
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/utils/functional.py",
line 225, in inner
self._setup()
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/utils/functional.py",
line 365, in _setup
self._wrapped = self._setupfunc()
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/middleware.py",
line 22, in 
request.user = SimpleLazyObject(lambda: get_user(request))
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/middleware.py",
line 10, in get_user
request._cached_user = auth.get_user(request)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/__init__.py",
line 167, in get_user
user_id = _get_user_session_key(request)
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/contrib/auth/__init__.py",
line 59, in _get_user_session_key
return get_user_model()._meta.pk.to_python(request.session[SESSION_KEY])
File
"/root/django/envs/wallet/lib/python3.4/site-packages/django/db/models/fields/__init__.py",
line 969, in to_python
params={'value': value},
django.core.exceptions.ValidationError: ["Value
'TBQqn1Cpz4aO1UNeDgKzmgvtW1ygTS' must be int."]

For what purpose we have introduced such a restriction?
Can I get around it without rewriting the whole authentication mechanism?
As the authenctication server uses Django with oauth2_provider package.

P.S. Sorry for bad English.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAANO9k%3DotApNwTt3BROFjn5EHHezPqM8ZftJYHQopZWfv68N5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Don't run python manage.py syncdb

[Faffafa Trtrtrtrt]

I create question 
in 
http://stackoverflow.com/questions/32999054/dont-run-python-manage-py-syncdb. 
Any one can answer it?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d1334ecc-3070-4968-b81f-ab1942841c8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: formset concurrency control

[Carsten Fuchs]

Hi Tim,

Am 08.10.2015 um 21:03 schrieb Tim Graham:

I think the problem is also described in 
https://code.djangoproject.com/ticket/15574.
Probably if we had a simple solution, that ticket wouldn't be open for 5 years. 
:-)


:-)

Yes, having read all of it, I too think that #15574 describes the same problem.

The more I think about it, reconstructing the queryset in the POST request by the same 
parameters that were used to construct the queryset for the initial formset data in the 
GET request, in *addition* to the primary keys in the POST request, seems like an 
increasingly good idea to me:


In formset validation, comparing the queryset objects with the PKs from the POST request 
should yield an exact match (validation successful).


If there is any mismatch, it is probably best to just tell the user that there was a 
problem (in some specific cases it might be possible to fix and/or communicate the 
mismatch, but not generally). He/she may lose some work (has to reload and fill in the 
entire form again), but that still seems a lot better to me than saving something that 
the user has not seen (or seen differently) and may come entirely surprising.


This approach looks reasonably simple and stable to me, and I'll definitively try it 
out. As a second but independent step, it should even be relatively easy to add 
fine-grained concurrency control to it as mentioned in my first post.


As always, any additional comments or thoughts would very much be appreciated!

Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5617D9F4.6070901%40cafu.de.
For more options, visit https://groups.google.com/d/optout.

reverse() error while importing view function

[klerp]

Hello!

I get noreversematch error for url 'home' at deployed site with debug True.
The same works well at localhost. 

I should make debug False for deployment but any reason why view function 
import fails only at live site?

Following are the details.
 
templates/site/base.html

  
Home


site/urls.py

from django.conf.urls import include, url
from django.contrib import admin
from django.contrib.auth import views as auth_views
from . import views
from django.conf.urls.static import static
from django.conf import settings


urlpatterns = [
url(r'^$', views.index, name='home'),


site/views.py

from django.http import HttpResponse
from django.http import HttpResponseRedirect
from django.shortcuts import render
from django.core.mail import send_mail
from django.core.urlresolvers import reverse
from cxl.forms import ContactUsForm

def index(request):
context = {}
return render(request, 'site/index.html', context)


Thanks,
Klerp

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a5153752-ff74-451b-bbd7-3404daabff10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Is it necessary to make a custom manager for the custom User model?

[Benjamin Smith]

I am making a custom user model using the AbstractBaseUser and
PermissionsMixin by following these two tutorials (tutorial-1
 and tutorial-2

).

This my model so far:

class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField('email address', unique=True, db_index=True)
username = models.CharField('username', unique=True, db_index=True)
joined = models.DateField(auto_now_add=True)
is_active = models.BooleanField(default=True)
is_admin = models.BooleanField(default=False)
is_staff = models.BooleanField(default=False)

USERNAME_FIELD = 'email'

def __unicode__(self):
return self.email


Now what I am confused about is that in tutorial-1
, the author
didn't made any custom manager for the custom User model. Instead he use
forms for creating user.

class RegistrationForm(forms.ModelForm):
email = forms.EmailField(label = 'Email')
password1 = forms.CharField(widget = forms.PasswordInput(), label =
"Password")
password2 = forms.CharField(widget = forms.PasswordInput(), label =
'Retype password')

class Meta:
model = User
fields = ['email', 'username', 'password1', 'password2']

def clean(self):
"""
Verify that the values entered into the password fields match
"""
cleaned_data = super(RegistrationForm, self).clean()
if 'password1' in self.cleaned_data and 'password2' in
self.cleaned_data:
if self.cleaned_data['password1'] !=
self.cleaned_data['password2']:
raise ValidationError("Password don't match.")
return self.cleaned_data

def save(self, commit=True):
user = super(RegistrationForm, self).save(commit=False)
user.set_password(self.cleaned_data['password1'])
if commit:
user.save()
return user


But in tutorial-2
,
its author made a custom manager for the custom User model.

class UserManager(BaseUserManager):

def create_user(self, email, password, **kwargs):
user = self.model(
email=self.normalize_email(email),
is_active=True,
**kwargs
)
user.set_password(password)
user.save(using=self._db)
return user

def create_superuser(self, email, password, **kwargs):
user = self.model(
email=email,
is_staff=True,
is_superuser=True,
is_active=True,
**kwargs
)
user.set_password(password)
user.save(using=self._db)
return user


Referencing with Django Docs, there's an example

of custom user model, and it uses custom manager. My question is, whether
it is ok not to make any other custom manager and if not what is the use of
creating a custom manager?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAM4YLWL4LNTdPdPwffTv0X0NvLMZmJRgrMboHqO7XajBPQW6FA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django admin suitable for external users?

[Derek]

I agree that for widespread "unknown" customers its probably not good.  I 
think that when working in close partnership with a small number of 
clients/customers (the way the funding is works is not really a big issue), 
who will receive training and a good user manual, then the admin (with some 
user-friendly tweaking) can be used.  I am also assuming that, in all 
likelihood, that other tools such as queries, data capture and 
visualisation tools will be built as is appropriate.

On Tuesday, 6 October 2015 17:29:14 UTC+2, ta...@pingmd.com wrote:
>
> Derek, my distinction would be based product ownership ... potentially 
> both would or could pay. So in other words "clients" would own the product 
> as their own, versus "customers" whom are paying for service without 
> ownership and control of product development.
>
> I have seen Django admin opened up to clients & partners as a content 
> management system but never have experienced it as a consumer product.
>
>
> On Tuesday, October 6, 2015 at 10:26:33 AM UTC-4, Derek wrote:
>>
>> What is the difference between a customer and client - I assume the 
>> former is paying?
>>
>> On Monday, 5 October 2015 22:12:14 UTC+2, ta...@pingmd.com wrote:
>>>
>>> Has anyone opened Django admin to customers, not just clients? If so, 
>>> what warranted such decision as appose to only exposing partial 
>>> functionality through a customized app?
>>>
>>> CONFIDENTIALITY NOTE: The information contained in this transmission may 
>>> be privileged and confidential, and is intended only for the use of the 
>>> individual or entity named above. If the reader of this message is not the 
>>> intended recipient, you are hereby notified that any dissemination, 
>>> distribution or copying of this communication is strictly prohibited. If 
>>> you have received this transmission in error, please immediately reply to 
>>> the sender that you have received this communication in error and then 
>>> delete it. Thank you.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e5b9ac42-7621-4baa-b3e3-f9b556fd3194%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.