Pinax Signup and Accounts

Question

Does anyone know a good link to documentation about Pinax signup and "Accounts". I'm trying to work out how to implement our sign-up process in Django / Pinax and am trying to navigate my way between Django's User and Profile classes and the Account class in Pinax..

The main issue for us is we have a sign-up form with several extra questions that must be answered at the point of requesting an account. Membership then needs to be accepted by an admin before the account is enabled. At which point, the answers to these extra questions will be stored in the user's profile.

I'm torn between two rival approaches.

1) Create the User and Profile object at the time of the request. But flag them as "pending" in some way, until approval.

2) Create some kind of alternative model class to temporarily store these values until approval. At which point I create the User and Profile objects and copy the information into them.

I'm trying to infer from the Pinax signup code which of these approaches is most "with the grain" of Pinax, but it's not clear.

So, experienced Django/Pinax developers. Which of these is the more "pinactic" way to go about things?

Answer 1

Most of the documentation is either here: http://pinaxproject.com/docs/dev/ or here: http://code.pinaxproject.com/wiki/ or else in the code base.

It's seems recently they've been working on the code more and documentation less since they're working up to a stable release so those docs aren't very up-to-date.

That said, Pinax already has a mechanism that delays activating accounts until they've validated their e-mail address (approach #1). The related settings are: ACCOUNT_REQUIRED_EMAIL and ACCOUNT_EMAIL_VERIFICATION so a search on the code base should revealed how/where they're used (which you may be able to extend to use for your extra questions).

I believe they accomplish this by giving each User an "Active" flag (Check out the User object in Admin) which isn't set to True until they verify their e-mail address. I vaguely remember setting this manually one time and still being unable to login with that particular User so you'll want to test this out.

Answer 2

There are two variants of (1): (a) you just rely on the active flag on User; (b) you denomormalize and have a similar flag on your profile to avoid a join.

The main challenge with approach (1) is that you then have to make sure that any time you are retrieving profiles, you filter them based on this flag. Of course, that's not an issue for something like Account which only the logged in user sees. But for Profile that could be a bit of a pain.

(2) doesn't have that problem. You could avoid some redundancy in that case by using an abstract base model shared by both your temporary profile and main profile models.

Bottom line is I don't think there's an obvious "pinactic" way to do it, although personally I'm leaning towards (2).