Feature suggestion: Extendable Registration Profiles about django-registration HOT 8 CLOSED

I am trying to figure out that, have you reached a proper solution?

from django-registration.

Have you considered a custom user model for the additional fields? This is one way, alternatively a account model with a 1:1 on the user can be used. I don't think extending the RegistrationProfile is the right approach. What is the benefit?

Cheers, Andrew

from django-registration.

@macropin,
Thanks for the suggestion. For my use case, I avoided a customer user model for the exact reason described in the documentation. It's usually more practical as you suggested to have a model, call it UserProfile, with a foreign key or one-to-one relation back to User.

I actually have a similar setup, but a GroupProfile model with a one-to-one relationship to Group. GroupProfile has additional foreign key relationships to other models as well.

During the user registration we process, we capture information related to both the GroupProfile and the additional models related to GroupProfile.

Essentially we capture a variety of data spanning three models, and don't want to create instances of those models unless we, as administrators of the service, approve the user and the provided details. I'm not sure if there is a better design for this process, but it's non-trivial to change it regardless. We might be overloading the functionality of django-registration, but it's working quite well for us nonetheless.

Does that use case scenario make more sense, even if it might be overly unique?

from django-registration.

I think RegistrationForm must be ModelForm of the UserModel() with fields-dependent behavior... May be with several basic customizable fields, e.g. using Django AbstractBaseUser.USERNAME_FIELD insted of UserModel().username, etc..
But it is big work for future.

from django-registration.

@dicato Did you get this sorted in the end? I would love to have the user need to enter a 'secret' word and choose something from a dropdown during the registration process to put in the UserProfile model.

from django-registration.

@willfurnell we used the above approach for awhile. When a User registered, we forced them to provide two additional pieces of information. We saved that information on our custom RegistrationProfile and then used it to pre-configure settings in our application.

Feedback from our users and a few people with expertise in user experience told us they did not like this process. We had created additional steps in our registration process and were absolutely losing users because of it.

Instead, we now have a very "standard" registration process where the User provides their username, email, and a password (only once by the way) and is immediately registered and logged in. The additional fields we were storing on the RegistrationProfile have been moved to custom models that behave akin to UserProfile and GroupProfile. We actually use Django's messages to indicate to the User what settings they must or should configure.

To summarize, we store the fields we care about on other models (UserProfile, GroupProfile) and decouple the User entering that information from the registration process in order to make the registration process as easy as possible.

I'm going to close this issue.

from django-registration.

@dicato Could you please explain more on your last approach? The registration just need username, email and password, but when do you require them to finish their profile? Thanks.

from django-registration.

@rylanchiu I've tried to address your question in the issue you filed about collecting User provided images: #123

from django-registration.