Create account that can either be a person or a group

[Karl Arunachal]

I want to create user accounts for my website. The account can be either a person or a group. So for person account I want to get different information from them (such as First name, Last Name, ...), and for group account get different information (such as Group name, ...). Basically different form for person account and group account. The account itself will have a unique primary key ( such as username/account id).

How should I do it? Should I make one to one relationship with account and person, and the same with account and group? Or create just on Account model and place a choice field to choose between Person and Group? Or how do you prefer I should do it?

Thank you

[James Schneider]

I want to create user accounts for my website. The account can be either a person or a group. So for person account I want to get different information from them (such as First name, Last Name, ...), and for group account get different information (such as Group name, ...). Basically different form for person account and group account. The account itself will have a unique primary key ( such as username/account id).

How should I do it? Should I make one to one relationship with account and person, and the same with account and group? Or create just on Account model and place a choice field to choose between Person and Group? Or how do you prefer I should do it?

While there is a philosophical difference between a 'person' and a 'group', for your use case, I don't believe there is a significant technical difference between the two. It sounds like an 'entity' will be able to log in either way, so ultimately you just have Accounts that are classified as either a single-user or are representative of a larger swath of users.

You can treat them as totally separate entities, and there may be a technical need to do so if your app requires tight coupling to specific functionality for each classification. However, in many cases, you won't treat either Account classification. I would do the following assuming a somewhat naive approach since I don't have the details of your use case. This is assuming that either a 'person' or a 'group' would be able to directly log in to you app:

Simply use Account as your primary 'user' ('user' meaning the entity that will allow for logging into the system and checking permissions, etc.). Combine your Group and Person models directly into Account (if they are both small), or as a single separate profile model (ie AccountProfile) if you have more that a couple fields in each classification (usually better to have a separate profile model in most cases). AccountProfile would contain fields that pertain to both a 'person' and a 'group', but only the fields in use for that particular classification would be populated.

For Account, you would add a field with choices to designate 'person' or 'group' classification (if you have many, or a growing list, you may need an FK to a Classification model that contains all of your possible classifications). Add a 1to1 FK from Account to AccountProfile. Account should only contain fields that are used when authenticating the user (username, password, etc.) and fields that would be needed on a regular basis throughout the app (display name, menu avatar location, etc.). All other fields should be moved to AccountProfile, which is manually and infrequently loaded on an as-needed basis.

That being said, there may be justification to keep the profile models separate for each entity type. You may have model methods that overlap as well. A method like account.get_display_name() may have a different set of actions for a person (return given + surname) vs. a group.(return given name). The differences will need to be accounted for in each of your model methods, or you may simply want separate models to avoid a collision in behavior between the two entity types.

As far as UI design goes, I would recommend looking at django-formtools, which provides the Django FormWizard that was previously integrated with Django. Django-formtools will allow you to build a multi-step form (wizard) that can provide different forms for each step based on the answers in the previous step. It has a slightly steep learning curve, but is likely what you need.

-James