I'm using django-registration in my application. I want to create different kinds of users with different profiles.
For example, one user is a teacher and another user is a student.
How can I modify registration to set the user_type and create the right profile?
Long answer :p
I've found The Missing Manual post invaluable for this kind of problem as it explains many of features of the django-profiles and django-registration systems.
I'd suggest using multi table inheritance on the single profile you're allowed to set via the AUTH_PROFILE_MODULE
For instance
#models.py
class Profile(models.Model):
#add any common fields here (first_name, last_name and email come from User)
#perhaps add is_student or is_teacher properites here
#property
def is_student(self):
try:
self.student
return True
except Student.DoesNotExist:
return False
class Teacher(Profile):
#teacher fields
class Student(Profile):
#student fields
django-registration uses signals to notify you of a registration. You should be creating the profile at that point so you are confident that calls to user.get_profile() will always return a profile.
The signal code used is
#registration.signals.py
user_registered = Signal(providing_args=["user", "request"])
Which means when handling that signal you have access to the request made. So when you POST the registration form include a field that identifies what type of user to create.
#signals.py (in your project)
user_registered.connect(create_profile)
def create_profile(sender, instance, request, **kwargs):
from myapp.models import Profile, Teacher, Student
try:
user_type = request.POST['usertype'].lower()
if user_type == "teacher": #user .lower for case insensitive comparison
Teacher(user = instance).save()
elif user_type == "student":
Student(user = instance).save()
else:
Profile(user = instance).save() #Default create - might want to raise error instead
except KeyError:
Profile(user = instance).save() #Default create just a profile
If you want to add anything to the model that is created, that isn't covered by default field values, at registration time you can obviously pull that from the request.
http://docs.djangoproject.com/en/1.2/topics/auth/#groups
Django groups are a great way to define what you are looking for.
You can have one User extended profile that will contain all attributes of teachers and students.
class MasterProfile(models.Model):
user = models.ForeignKey(User, unique=True)
# add all the fields here
Then define groups: teacher and student and you associate each MasterProfile to either a teacher or a student.
Django Group table can help you define your various roles and allocate users to groups correctly.
I had the same issue and I tried the answer suggested by Chris, however it didn't work for me.
I'm only a newbie in Django, but I think the args taken by handler create_profile should match those under providing_args by signal user_registered, and in Chris's answer they don't (I think they probably match those passed by signal post_save, which I've seen used in the Missing Manual that he quotes)
I modified his code to make args match:
def create_profile(sender, **kwargs):
"""When user is registered also create a matching profile."""
request, instance = kwargs['request'], kwargs['user']
# parse request form to see whether profile is student or teacher
try:
user_type = request.POST['usertype'].lower()
print(user_type)
if user_type == "teacher": #user .lower for case insensitive comparison
Teacher(user = instance).save()
elif user_type == "student":
Student(user = instance).save()
else:
Userprofile(user = instance).save() #Default create - might want to raise error instead
except KeyError:
Userprofile(user = instance).save() #Default create just a profile
and seems to be working now
Related
My app has Users that can be Doctors/Patients/Secretaries. To create a Doctor, therefore, I perform two POST requests: one for the creation of a User and one for a Doctor. The way I do this, the User has to be created first so that I can later create the Doctor (Doctor requires a 'User' field). I am using Django Rest Framework to create the API.
class User(AbstractUser):
# defined roles so when I retrieve user, I know to perform a
# request to api/doctors/ or api/secretaries/ etc depending on role.
ROLES = (
('d', 'Doctor'),
('s', 'Secretary'),
('p', 'Patient'),
)
role = models.CharField(
max_length=1, choices=ROLES, blank=True, default='p', help_text='Role')
class Doctor(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE)
national_id = models.CharField(max_length=32, blank=False)
...
Since I'm new to Django, I don't know if two requests is the standard/best way of creating this User/Doctor.
This comes to mind as I am also thinking of the GET methods which will be performed later on (two GET requests when a Doctor logs in if I want to retrieve all of their info (User/Doctor)?)
I read about subclassing, which would be something like Doctor(User), then the only necessary request would be a single POST to create a Doctor (which would alongside create the User). I am, however, skeptical of subclassing the User as I read at least 3 SO answers stating it could cause problems in the future.
have a look at this good tutorial https://simpleisbetterthancomplex.com/tutorial/2018/01/18/how-to-implement-multiple-user-types-with-django.html which explain 2 different approches
extend AbstractUser with flags is_doctor, is_secretary, is_patient
class User(AbstractUser):
is_doctor = models.BooleanField('Doctor status', default=False)
is_secretary = models.BooleanField('Secretary status', default=False)
is_patient = models.BooleanField('Patient status', default=False)
using roles which suites your case:
class Role(models.Model):
'''
The Role entries are managed by the system,
automatically created via a Django data migration.
'''
ROLE_CHOICES = (
('d', 'Doctor'),
('s', 'Secretary'),
('p', 'Patient'),
)
id = models.PositiveSmallIntegerField(choices=ROLE_CHOICES, primary_key=True)
def __str__(self):
return self.get_id_display()
class User(AbstractUser):
roles = models.ManyToManyField(Role)
Problem
Determine best practices for handling multiple user types and adding attributes to a user in Django.
Solution
The following is are recommendations based on design patterns that have been commonly used in Django since version 0.96. These recommendations are present in Django’s documentation (see: References).
Roles
Use Django’s built in permissions module for role and group management instead of rolling your own role and group management.
Instead of a model for each type, create a single UserProfile model, relegating user types to being managed by permissions model.
I recommend using a data migration to add groups so that default groups are automatically seeded on initial migrate call—this reduces overhead for anyone setting up your project for the first time.
OneToOne
Use Django OneToOne field instead of ForeignKey.
UserProfile and Signals
Create a signal that creates a UserProfile on User create.
Example
class UserProfile(models.Model):
user = models.OneToOne(“User”, on_delete=models.CASCADE)
national_id = models.CharField(max_length=32,
def create_profile(sender, **kwargs):
user = kwargs["instance"]
if kwargs["created"]:
user_profile = UserProfile(user=user)
user_profile.save()
post_save.connect(create_profile, sender=User)
References
Django permissions (groups): https://docs.djangoproject.com/en/3.1/topics/auth/default/#groups
Django Data Migrations: https://docs.djangoproject.com/en/3.1/topics/migrations/#data-migrations
Django extending User model recommendation: https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#extending-django-s-default-user
Django post_save signal: https://docs.djangoproject.com/en/3.1/ref/signals/#post-save
in your case (the model you made) you can create the doctor and the user in one post request to the doctor creation by overriding the create function for the
from rest_framework.generics import CreateAPIView, ListAPIView
class CreateDoctorViewSet(CreateAPIView, ListAPIView):
def create(self, request, *args, **kwargs):
data = self.request.data
user_dict_keys = ["username", "email", "first_name", "last_name"]
user_dict = {key: data.pop(key, None) for key in user_dict_keys}
user_dict['role'] = "d"
user_serializer = UserSerializer(data=user_dict)
# if it's not valid it will return the exception details for the requester
user_serializer.is_valid(raise_exception=True)
user = user_serializer.create(user_dict)
user.set_password(data['password'])
data.pop("password", None)
user.save()
response = super().create(request, *args, **kwargs)
if response.statu_code == 201:
return response
# if an error happened while in the doctor model (model error or serializer error) >> delete the created user
user.delete()
return response
or made a little more DRY :
from rest_framework.generics import CreateAPIView, ListAPIView
def create_user(self):
data = self.request.data
user_dict_keys = ["username", "email", "first_name", "last_name"]
user_dict = {key: data.pop(key, None) for key in user_dict_keys}
user_dict['role'] = "d"
user_serializer = UserSerializer(data=user_dict)
# if it's not valid it will return the exception details for the requester
user_serializer.is_valid(raise_exception=True)
user = user_serializer.create(user_dict)
user.set_password(data['password'])
data.pop("password", None)
user.save()
return user
class CreateDoctorViewSet(CreateAPIView, ListAPIView):
def create(self, request, *args, **kwargs):
user = create_user(request)
response = super().create(request, *args, **kwargs)
if response.statu_code == 201:
return response
# if an error happened while in the doctor model (model error or serializer error) >> delete the created user
user.delete()
return response
Personal Advices:
in the case you're providing the User model has one role so it's better to make the user field in the Doctor class OneToOne instead of ForeignKey.
Of course if you have cases where there are people for example converting from Doctor to Secretary and you want them to switch between roles on the same account you can keep the ForeignKey on Doctor model but you have to make multiple roles possible in the user model.
What you mean by subclassing it is called Multi table inheritance. And there is no problem in using it, no side effects and it is perfectly compatible with Django Rest Framework (which you have tagged). This is the way it works:
class User(AbstractUser):
# Your common fields for all user types.
class Doctor(User):
national_id = models.CharField(max_length=32, blank=False)
class Secretary(User):
# Your specific fields for secretary model
class Patient(User):
# Your specifict fields for patient model
In background, it uses a OneToOne relationship for each subtype.
Advantajes of using Multi table inheritance:
It is simple and elegant: you don't have to take care of different tables, queries, etc; Django does it for you.
It also unsures a good and formalized structure of your database: different tables for common and specific data in OneToOne relationship.
It is suitable for your needs? That depends.
If each subtype has its own specific fields -> use multi table inheritance without doubt.
If each subtype has the same set of fields but different behaviours (different class/model methods, code, etc) -> use proxy models.
If all the subtypes have the same set of fields and the same behaviour (same class/model methods, code, etc) -> use role based approach (one field identifying the role).
(extra) If you have dozens of subtypes, each one of them has different fields and you don't care too much about database formalization -> Don't use Multi table inheritance. In this case, you can use a mix of role based approach with JSON fields (for storing all the specifict fields) and proxy models (for handling different behaviours)**.
I've created UserProfile model in my application:
class UserProfile(models.Model):
user = models.OneToOneField(settings.AUTH_USER_MODEL,
on_delete=models.CASCADE,
primary_key=True,
verbose_name=_('user'),
related_name='user_profile')
locality = models.CharField(max_length=85)
voivodship = models.CharField(max_length=20,
choices=Vovoidship.choices,
validators=[Vovoidship.validator])
postcode = models.IntegerField()
street = models.CharField(max_length=75)
building = models.SmallIntegerField()
premises = models.CharField(max_length=80)
phonenumber = PhoneNumberField(blank=True)
#staticmethod
def post_save_create(sender, instance, created, **kwargs):
if created:
profile, created = UserProfile.objects.get_or_create(user=instance)
post_save.connect(UserProfile.post_save_create, sender=User)
Now, I felt into my own trap. I don't want to loose constraints and keep the requirement in the database that address fields need to be filled up. I'm using django-allauth. While using the setting ACCOUNT_SIGNUP_FORM_CLASS = 'management.forms.SignupForm' solves the problem for traditional sign up form, if the user logs in first time using the social account I got hit by constraint violation for obvious reasons:
IntegrityError at /accounts/google/login/callback/
null value in column "postcode" violates not-null constraint
DETAIL: Failing row contains (4, , , null, , null, , ).
Hence the question, how to correctly implement the request for filling up the information for fields in the application UserProfile? I'm surprised that django-allauth doesn't have a build in handler for that the same way as ACCOUNT_SIGNUP_FORM_CLASS is done.
As I'm new to Django please assume I rather don't know something than it should be obvious. Thanks.
I think you need to:
1.- Create your custom Signup Class, for you to do the additional work
class SignupForm(forms.Form):
locality = forms.CharField(max_length=85)
voivodship = forms.CharField(max_length=20)
postcode = forms.IntegerField()
etc.
def signup(self, request, user):
# I think the profile will exist at this point based on
# your post_save_create. But if not, just create it here
if user.user_profile:
user.user_profile.locality = self.cleaned_data['locality']
user.user_profile.voivodship = self.cleaned_data['voivodship']
user.user_profile.postcode = self.cleaned_data['postcode']
...
user.user_profile.save()
2.- Set ACCOUNT_SIGNUP_FORM_CLASS = 'yourproject.yourapp.forms.SignupForm' to have allauth use your form
3.- Set SOCIALACCOUNT_AUTO_SIGNUP=False to ensure the form is presented even with social signup.
With some credits to davka I've managed to form a working solution which required creating UserProfile object inside signup() method of the SignupForm class, but because of database/model constrains it has be be filled with data during creation. The result:
class SignupForm(ModelForm):
first_name = CharField()
last_name = CharField()
class Meta:
model = UserProfile
exclude = ['user', 'phonenumber']
def signup(self, request, user):
user.first_name = self.cleaned_data['first_name']
user.last_name = self.cleaned_data['last_name']
profile, created = UserProfile.objects.get_or_create(
user=user, defaults={
'locality': self.cleaned_data['locality'],
'voivodship': self.cleaned_data['voivodship'],
'postcode': self.cleaned_data['postcode'],
'street': self.cleaned_data['street'],
'building': self.cleaned_data['building'],
'premises': self.cleaned_data['premises'],
})
if created: # This prevents saving if profile already exist
profile.save()
The solution doesn't totally fit into DRY principle, but shows the idea. Going further it could probably iterate over results matching model fields.
Two elements need to be set correctly in settings.py:
ACCOUNT_SIGNUP_FORM_CLASS = 'yourapp.forms.SignupForm' to enable this form in allauth
SOCIALACCOUNT_AUTO_SIGNUP = False this - contrary to the intuition - let the allauth display the form before finishing the signup if the user selected social sign in but don't have an account; it works safely if the account already exists (username and/or e-mail address depending on other settings) as just does't allow to finish registration (why they call it sign up?) and the user is forced to log in and link social account.
In my project I have two different types of users: teacher and student, each with their own profile data.
After searching for the best approach it seems the way to go forward is using multi-table inheritance:
class BaseProfile(models.Model):
user = models.OneToOneField(User)
profile = models.CharField (max_length=10, choices={'teacher', 'student'})
# other common fields
class Teacher(BaseProfile):
# teacher specific fields
class Student(BaseProfile):
# student specific fields
And in settings.py: AUTH_PROFILE_MODULE = myapp.BaseProfile.
Now I want to implement the same functionalities as in django-profiles:
create profiles
edit profiles
display profiles
I have a good idea how to do the edit and display part when I have the correct value in the field profile of BaseProfile.
The problem:
Now I want the creation of the profile to be done automatically (and in the right db: Teacher or Student) directly when a user is created by using a signal.
The field profile should contain the value "student" when the user registers through the site via the registration form. The value should be "teacher" when the admin creates a new user through the admin interface.
Anyone an idea how I can accomplish this? Probably I need to write a custom signal, something like the below, and send it from the User Model, but didn't found a working solution yet:
def create_user_profile(sender, instance, request, **kwargs):
if request.user.is_staff:
BaseProfile(user=instance, profile='teacher').save()
else:
BaseProfile(user=instance, profile='student').save()
Other and better approaches are of course also welcome!
Thanks!
In my opinion it isn't a good approach.
I would recommend doing 1 unified profile which will contain an option:
user_type = models.CharField(choices=[your_choices], max_length=4)
Then in models you would create two forms - 1 for teacher and 1 for student.
class ProfileFOrm(forms.ModelForm):
def __init__(self, *args, **kwargs):
super(BaseProfileForm, self).__init__(*args, **kwargs)
for name in self.fields:
self.fields[name].required = True
class TeacherProfile(ProfileForm):
class Meta:
model = Profile
fields = ('your_fields')
class StudentProfile(ProfileForm):
class Meta:
model = Profile
fields = ('school')
That's just my idea for that :)
Edited
Profile edition:
view.
def profile(request):
p = get_objects_or_404(ProfileModel, user=request.user)
return TemplateResponse(request, 'template.html', {'profile': p})
In models we need a function to check if user is a student or a teacher, so:
class Profile(models.Model):
... your fields here...
def get_student(self):
return self.user_type == 1
In templates:
{% if profile.get_student%}
>>>>get all data for students ex: <<<<
{{profile.name}}
{% endif %}
{% if profile.get_teacher %}
....
I'm having some issues with user profiles in Django currently.
I followed the recommendations and created a user profile:
class UserProfile(models.Model):
user = models.OneToOneField(User)
is_teacher = models.BooleanField(verbose_name = "Teacher", help_text = "Designates whether this user is a teacher and can administer and add students and classes")
school = models.ForeignKey(School)
def __unicode__(self):
return self.user.username
def save(self, *args, **kwargs):
if not self.pk:
try:
p = UserProfile.objects.get(user=self.user)
self.pk = p.pk
except UserProfile.DoesNotExist:
pass
super(UserProfile, self).save(*args, **kwargs)
I also inlined this user profile into my User admin page. This is what I use to make sure that a user profile is created along with a user:
def create_user_profile(sender, instance, created, **kwargs):
"""Create the UserProfile when a new User is saved"""
if created:
print "User Profile Creation: ", created
UserProfile.objects.get_or_create(user=instance)
The issue arises when I go to add a new user. Before adding the school field, I was able to fill everything in and it would work great. After adding the school field, I get an IntegrityError that states that userprofile.school_id cannot be null. Where am I going wrong here?
I believe the issue is that the choice of school is not being passed to the get_or_create and so when it goes to create the UserProfile, it sees nothing. How then did it work before, when clicking the checkbox for is_teacher? Also, how would I go about fixing this?
Yes, the choice of school isn't getting passed, it's not getting passed here:
UserProfile.objects.get_or_create(user=instance)
You're only setting a user, and trying to create the profile.
Add null=True, blank=True to the school field, or figure out what the school choice was, and pass that in:
UserProfile.objects.get_or_create(user=instance, school=school)
Django 1.2 allows usernames to take the form of an email address.
Changed in Django 1.2: Usernames may
now contain #, +, . and - characters
I know that's a much-requested feature, but what if you don't want the new behavior? It makes for messy usernames in profile URLs and seems to break django-registration (if a user registers an account with an email-style username, the link in the django-registration activation email returns 404).
Does anyone have a recipe for restoring the old behavior and disabling email-style usernames?
There is no straightforward way to revert back to old behavior.
The easiest way to handle this would be to enforce client and server side validation of usernames according to your demands. django-registration is not an actively developed component, I wouldn't count on anything coming from that direction. Just add some extra validation on your side.
To quote Jacob on this matter:
[...] another common request is to allow the
use of email addresses as usernames.
Custom registration/signup forms can
deal with further restrictions.
django-registration actually wasn't the problem here. The problem was that I had subclassed its RegistrationForm, redefining the username field with new help_text. In so doing, I had prevented it from using its own regex field. To fix this, I had to pull a few bits and pieces from RegistrationForm into my EnhancedRegistrationForm subclass.
Note the regex line, which mirrors the old-style username character restrictions (which is what I want).
from registration.forms import RegistrationForm
# Carry these over from RegistrationForm - needed in the form definition below
attrs_dict = {'class': 'required'}
from django.utils.translation import ugettext_lazy as _
class EnhancedRegistrationForm(RegistrationForm):
first_name = forms.CharField(label='first name', max_length=30, required=True)
last_name = forms.CharField(label='last name', max_length=30, required=True)
username = forms.RegexField(regex=r'^\w+$',
max_length=30,
widget=forms.TextInput(attrs=attrs_dict),
help_text='Email addresses cannot be used as usernames.',
required=True,
label=_("Username"),
error_messages={'invalid':"You cannot use an email address as a username, sorry."})
class Meta:
fields = ('first_name','last_name','username','email','password1','password2')
def save(self, *args, **kwargs):
"""
Overriding save, so call the parent form save and return the new_user
object.
"""
new_user = super(EnhancedRegistrationForm, self).save(*args, **kwargs)
new_user.first_name = self.cleaned_data['first_name']
new_user.last_name = self.cleaned_data['last_name']
new_user.save()
return new_user