As I mentioned yesterday, the first set of models I’m working on are for the People and Organization applications. I’m going to outline them here so that Andrew can put together basic wireframes for how the information will be structured on the view. We’re going for a basic profile view where the contact information is one part and the activity stream is the other part.
I’m adding the type of field the data is for the edit view. Users will be able to edit their own profiles and the organization profiles they are the administrator for. CoPress admins will be able to edit any profile and any organization profile.
People – Profile model extends the Django User model and includes:
- First name (text field)
- Last name (text field)
- Date created
- Position (text field)
- Organization (foreign key to an existing organization within the system)
- Phone (dropdown with multiple options and ability to add multiple phone numbers)
- Email (dropdown with multiple options and ability to add multiple phone numbers)
- IM (dropdown with multiple options and ability to add multiple phone numbers)
- Websites (dropdown with multiple options and ability to add multiple phone numbers)
- Address/Location (multiple text fields)
- Photo (uploaded file
- Bio (multi-line text field)
Organization model includes:
- Name
- Date created
- Slug (unique)
- Summary (multi-line text field
- Websites (same as People profile
- Email (ditto)
- Phone (ditto)
- Address
- Photo
The organization view will also have a list of staff depending on which users in the system have the organization in their profile. The user’s position and photo in the staff view will be pulled from their personal profile. Lastly, every object in the system will have the ability to be tagged with various topics. Clicking on fields like Location and Position will produce a filter view where you can see all of the People or Organizations with that piece of metadata.
Some comments:
1. It seems odds to have an organization’s members stored in the member, not in the organization. This is generally handled as a M2M key in the organization.
2. All your drop downs are actually separate inline models—you can just copy the code from CoHost
3. You might not want position as a text field, or at least have some other kind of ‘rank’ signifier. This might be best handled as a custom M2M connection table, such that each connection to an organization also stores rank/permissions—just look at the connection between schools and contracts in CoHost.
4. Users will have profiles, right? If so, they’ll also need slugs. I’d also recommend giving ALL models date created and date modified fields, so you can keep track of updates and changes.
With addresses, if you are mapping these people, you don’t want to ping Google’s map server every time you make a map to figure out the long/lat to place things on the map. Instead, you should have a function that runs when addresses are added/update that sets hidden longitude and latitude fields.
Thanks for the feedback, Miles. I’m starting this from scratch because it’s a learning process as much as anything else, but I am refactoring a lot of your code from CoHost.
1. I’ll look at M2M keys. I don’t have an opinion one way or the other.
3. I think I’m going to lean towards having positions like Editor in Chief, Webmaster, etc. stay as a text field, but then the Organization will also have a permissions model where certain members have certain permissions. Does that make sense?
4. User slugs will just be the username, I believe.
Good point about mapping. Initially what I’d like to do is have a filter by location list view where you can see, say, all of the people and organizations within a specific state. Eventually it would be nice to put that information on an actual map.
Ah, “M2M” means ManyToMany. Sorry for being dense. Could you have both relationships (Organization as a ForeignKey to Person, and Person as a ManyToMany to Organization)?
Here’s a couple screenshots of initial wireframes that I did this morning.
News organization page – http://andsp.com/aUr6x
Individual page – http://andsp.com/aUqb4
Thoughts and feedback are certainly welcome.
@Miles I figured it out. Disregard my earlier comment re: ForeignKey vs. ManyToMany
You can do reverse lookups—so yes, you could find out what organizations a user is a member of. I’d still recommend user permissions being stored in the M2M field instead of inside the organization. It gives you a bit more flexibility, but is more complicated, I guess.