The current SignupForm.save contains old django-friends invitation handling code and is hard to understand and customize.
I suggest to extract any email confirmation related code to separate method, keep the base form simple and provide legacy DjangoFriendsSignupForm or just get rid of that code (currently it is not triggered because no confirmation_key is passed to the form from the signup view anyway).
I also added KaleoSignupForm to the patch as example how easy it is to provide custom email verification method using the new approach.
I include full commit history in case you want to follow my way of thinking and code refactoring steps.
Pass confirmation key/code param to account.signup form as initial va…
Moved common user creation code out of if statements.
Moved old django-friends confirmation code to separate method of Sign…
Added missing call param.
Simplifying signup form code.
Added a bit of doc.
Returning verification status from SignupForm.handle_confirmation.
Don't set user as inactive when his email address was already verified. Otherwise he won't have a chance to verify email address because he won't receive any confirmation message.
Don't tie confirmation key to SignupCode model in case some other ver…
…ification system is used in forms.
Wrapped user creation in db transaction block.
Otherwise User object without attached EmailAddress may be created if something goes wrong during the process.
Reorganized code and updated docstring.
Abstracted email confirmation code during signup process.
Added default email confirmation handler to SignupForm and moved legacy django-friends join invitation code to DjangoFriendsSignupForm.
Added KaleoSignupForm as example of handling user to user invitations…
… and marking email address as verified.
Removed unused import.
I need to do a bit more thinking with how I want this to work. I have been thinking a lot lately with how to fix pinax.apps.account. I don't think this is quite what I want. However, I am glad that you have made a start on this and getting me to think about pinax.apps.account differently.
We are changing the direction of account related bits in Pinax. We've held some discussions during PyCon 2012 and have decided it is best to move pinax.apps.account outside of Pinax. We've created django-user-accounts where all future efforts will take place. I do believe it solves the issues you've tried to solve here.
I am very appreciative of the work you've put in here and I hope I can get you directed towards the new effort. I look forward to any new ideas you can bring to the table. Thank you!