How can I change the "account already exists" message in Django allauth? - django

When trying to log in with a social account while there already being an account with that email, the following message shows:
An account already exists with this e-mail address. Please sign in to that account first, then connect your Google account.
Now I would like to change that message. At first I tried to override ACCOUNT_SIGNUP_FORM_CLASS = 'mymodule.forms.MySignupForm' and gave it my own raise_duplicate_email_error method, but that method is never called.
The form looks like this:
class SignupForm(forms.Form):
first_name = forms.CharField()
last_name = forms.CharField()
boolflag = forms.BooleanField()
def raise_duplicate_email_error(self):
# here I tried to override the method, but it is not called
raise forms.ValidationError(
_("An account already exists with this e-mail address."
" Please sign in to that account."))
def signup(self, request, user):
# do stuff to the user and save it
So the question is: How can I change that message?

If you want the raise_duplicate_email_error method to be called you must inherit from a form class that actually calls self.raise_duplicate_email_error()! However you are just inheriting from forms.Form!
Let's take a look at the code of forms.py at https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py. We can see that raise_duplicate_email_error is a method of BaseSignupForm (and is called from its clean_email method).
So you need to inherit from either allauth.account.forms.BaseSignupForm or allauth.account.forms.SignupForm (which also inherits from BaseSignupForm and adds some more fieldds to it).
Update after OP's comment (that the BaseSignupForm is derived from the _base_signup_form_class() function, that itself imports the form class defined in the SIGNUP_FORM_CLASS setting ): Hmm you are right. The problem is that the raise_duplicate_email_error and clean_email methods of BaseSignupForm don't call the same-named methods of their ancestors through super (so your raise_duplicate_email_error is never called).
Let's see what the view does: If you have added the line url(r'^accounts/', include('allauth.urls')), to your urls.py (which is the usual thing to do for django-allauth), you'll see the line url(r"^signup/$", views.signup, name="account_signup"), in the file https://github.com/pennersr/django-allauth/blob/13edcfef0d7e8f0de0003d6bcce7ef58119a5945/allauth/account/urls.py and then in the file
https://github.com/pennersr/django-allauth/blob/13edcfef0d7e8f0de0003d6bcce7ef58119a5945/allauth/account/views.py you'll see the definition of signup as signup = SignupView.as_view(). So let's override SignupView to use our own form and then use our class view for the account_sigunp !
Here's how to do it:
a. Create your custom view that inherits SignupView and overrides the form class
class CustomFormSignupView(allauth.accounts.views.SignupView):
form_class = CustomSignupForm
b. Create a custom form that inherits from SignupForm and overrides the email validation message
class CustomSignupForm(allauth.accounts.forms.SignupForm ):
def raise_duplicate_email_error(self):
# here I tried to override the method, but it is not called
raise forms.ValidationError(
_("An account already exists with this e-mail address."
" Please sign in to that account."))
c. In your own urls.py add the following after include('allauth.urls') to override the account_signup url
url(r'^accounts/', include('allauth.urls')),
url(r"^accounts/signup/$", CustomFormSignupView.as_view(), name="account_signup"),``

After creating your CustomSignupForm(allauth.accounts.forms.SignupForm ) that overrides the raise_duplicate_email_error method, you can, with django-allauth version 0.18, add the following to your settings file:
SOCIALACCOUNT_FORMS = {
'signup': 'path.to.your.custom.social.signup.form.CustomSignupForm'
}
The new raise_duplicate_email_error method should be called now.
Hope this helps you.

Related

Create a User Profile or other Django Object automatically

I have setup a basic Django site and have added login to the site. Additionally, I have created a Student (Profile) model that expands upon the built in User one. It has a OneToOne relationship with the User Model.
However, I have yet not come right with forcing the user to automatically create a Profile the first time they log in. How would I make sure they are not able to progress through anything without creating this?
I have tried by defining the following in views:
def UserCheck(request):
current_user = request.user
# Check for or create a Student; set default account type here
try:
profile = Student.objects.get(user = request.user)
if profile == None:
return redirect('/student/profile/update')
return True
except:
return redirect('/student/profile/update')
And thereafter adding the following:
UserCheck(request)
at the top of each of my views. This however, never seems to redirect a user to create a profile.
Is there a best way to ensure that the User is forced to create a profile object above?
Looks like you're attempting to do something similar to Django's user_passes_test decorator (documentation). You can turn the function you have into this:
# Side note: Classes are CamelCase, not functions
def user_check(user):
# Simpler way of seeing if the profile exists
profile_exists = Student.objects.filter(user=user).exists()
if profile_exists:
# The user can continue
return True
else:
# If they don't, they need to be sent elsewhere
return False
Then, you can add a decorator to your views:
from django.contrib.auth.decorators import user_passes_test
# Login URL is where they will be sent if user_check returns False
#user_passes_test(user_check, login_url='/student/profile/update')
def some_view(request):
# Do stuff here
pass

Django - Extra context in django-registration activation email

I'm using django-registration for a project of mine.
I'd like to add some extra contextual data to the template used for email activation.
Looking into the register view source, I cannot figure out how to do it.
Any idea ?
From what I remember, you need to write your own registration backend object (easier then is sounds) as well as your own profile model that inherits from RegistrationProfile and make the backend use your custom RegistrationProfile instead (This model is where the email templates are rendered and there is no way to extend the context, so they need to be overwritten)
A simple solution is to rewrite the send_activation_email
So instead of
registration_profile.send_activation_email(site)
I wrote this in my Users model
def send_activation_email(self, registration_profile):
ctx_dict = {
'activation_key': registration_profile.activation_key,
'expiration_days': settings.ACCOUNT_ACTIVATION_DAYS,
'OTHER_CONTEXT': 'your own context'
}
subject = render_to_string('registration/activation_email_subject.txt',
ctx_dict)
subject = ''.join(subject.splitlines())
message = render_to_string('registration/activation_email.txt',
ctx_dict)
self.email_user(subject, message, settings.DEFAULT_FROM_EMAIL)
And I call it like this
user.send_activation_email(registration_profile)
I don't get what it is your problem but the parameter is just in the code you link (the last one):
def register(request, backend, success_url=None, form_class=None,
disallowed_url='registration_disallowed',
template_name='registration/registration_form.html',
extra_context=None)
That means you can do it from wherever you are calling the method. Let's say your urls.py:
from registration.views import register
(...)
url(r'/registration/^$', register(extra_context={'value-1':'foo', 'value-2':'boo'})), name='registration_access')
That's in urls.py, where usually people ask more, but, of course, it could be from any other file you are calling the method.

Use proxy class instead of User for request.user

I have a meta class for the Django User model that I use to add extra methods (overly simplified version):
# project.models.pie_lover.py
from django.contrib.auth.models import User
class PieLover(User):
class Meta:
app_label = "core"
proxy = True
def likes_pie(self):
return True
In my view, I wish to get the logged in PieLover and see if he likes pie (silly thing to do because a PieLover always loves pie, but in a real world situation this may not be the case). My problem lies in the way Django logs in the users, I use the built-in login(request) function for this and as a result the object stored in request.user is a User object, not a PieLover.
# project.views.like_pie.py
from ..models.pie_lover import PieLover
def index(request):
pie_lover = request.user
if pie_lover.likes_pie():
print "Try pie, try!"
else:
print "BLASPHEMER!"
If I try to do this Django tells me that the User object has no method likes_pie which is to be expected as request.user is not a PieLover instance.
As a quick workaround I just get the PieLover which has the same ID as the User but that means an extra DB hit.
How can I make Django use PieLover by default in the request?
I was thinking that instead of making another database query to get the proper PieLover object to create a new PieLover object and pass request.user to it at initialization but I don't know what the implications of this are.
After poking around I found, what seems to me, the easiest and non-hackish way to access the PieLover methods for a given User instance. I have added this to a custom middleware:
from models.pie_lover import PieLover
class PieLoverMiddleware(object):
def process_request(self, request):
request.pie_lover = PieLover(request.user)
How can I make Django use PieLover by default in the request?
You don't.
Read this before you do anything else: https://docs.djangoproject.com/en/1.3/topics/auth/#storing-additional-information-about-users
Your "extension" to user should be a separate model with all of your extension methods in that separate model.
You can then navigate from User (in the request) to your extension trivially using the get_profile() method already provided.
from django.contrib.auth import models as auth_models
def _my_func(self):
return True
auth_models.User.my_func = _my_func

overriding methods of ModelAdmin

I am working on a Django project where any time an admin does something in the admin console (CRUD), a set of people gets notified. I was pointed to three methods on ModelAdmin called log_addition, log_created and log_deleted which save all the necessary info into a special database called "django_admin_log".
I placed the following code into my admin.py:
class ModelAdmin(admin.ModelAdmin):
def log_addition(self, request, object):
subject = 'admin test of creation'
message = 'admin creation detected'
from_addr = 'no_reply#example.com'
recipient_list = ('luka#example.com',)
send_mail(subject, message, from_addr, recipient_list)
return super(ModelAdmin, self).log_addition( *args, **kwargs )
This code however, gets ignored when I create new users. Many posts actually recommend to create a different class name (MyModelAdmin) and I am not entirely sure why - the point is to override the existing model. I tried it, but with the same result. Can anyone point me in the right direction please? How exactly do you override a method of an existing class and give it some extra functionality?
Thank you!
Luka
EDIT: I figured it out, it seems that I had to unregister and re-register User for my change to work.
remove the return at the end.
If that doesn't work, you can instead put the code in a function called add_view:
class ModelAdmin(admin.ModelAdmin):
add_view(self, request):
...
super(ModelAdmin, self).add_view( *args, **kwargs)
This function can be overwritten to add functionality to the admin's view. If you look at the admin code:
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L923
you will see that the function you have tried to overwrite is called from within the add_view function so you could equally put the code here

Error when wrapping the view of a 3rd-party Django app? (Facebook, django-socialregistration, django-profiles)

I'm using django-socialregistration to manage my site's connection with Facebook.
When a user clicks the "Connect with Facebook" button, I am able to automatically create a new Django user and log them in. However, I also need to create a UserProfile (my AUTH_PROFILE_MODULE) record for them which contains their Facebook profile information (email, name, location).
I believe I need to override socialregistration's "setup" view so I can do what I need to do with UserProfile. I've added the following to my project's urls.py file:
url( r'^social/setup/$', 'myapp.views.socialreg.pre_setup', name='socialregistration_setup'),
My custom view is here "/myapp/views/socialreg.py" and looks like:
from socialregistration.forms import UserForm
def pre_setup(request, template='socialregistration/setup.html',
form_class=UserForm, extra_context=dict()):
# will add UserProfile storage here...
return socialregistration.views.setup(request, template, form_class, extra_context)
The socialregistration view signature I'm overriding looks like this:
def setup(request, template='socialregistration/setup.html',
form_class=UserForm, extra_context=dict()):
...
I'm getting the error "ViewDoesNotExist at /social/setup/: Could not import myapp.views.socialreg. Error was: No module named socialregistration.views" when I try the solution above.
The socialregistration app is working fine when I don't try to override the view, so it is likely installed correctly in site-packages. Anyone know what I'm doing wrong?
OK, as Tim noted, this particular problem was path related.
Bigger picture, the way to accomplish what I wanted (creating a linked UserProfile when django-socialregistration creates a user) is best done by passing in a custom form into socialregistration's "setup" view, as the author suggested here: http://github.com/flashingpumpkin/django-socialregistration/issues/issue/36/#comment_482137
Intercept the appropriate url in your urls.py file:
from myapp.forms import UserForm
url('^social/setup/$', 'socialregistration.views.setup',
{ 'form_class': UserForm }, name='socialregistration_setup'),
(r'^social/', include('socialregistration.urls')),
You can base your UserForm off socialregistration's own UserForm, adding in code to populate and save the UserProfile.