I got to thinking that we are maybe putting the cart before the horse and need to clarify the goals of this project. I see several, I'm sure others will see them differently or have completely different goals. Here are mine:
-
I want to be able to designate a specific content type as equivalent to a user record. There should only be one type that has this status so there is no question about which content type is the 'primary' user profile.
-
I want to be able to designate additional content types as types that provide additional user information, similar to the role of the profile module now. There could be several of these types for any one user record.
-
I want to be able to link more than one userprofile node to a user record. This would be for situations where I have two or more individuals who share an email address (like many family members do) where I still need to track their names, event signups, etc. separately.
-
I want to have userprofile nodes that have no link to a user record for people who do not have an email address or who won't actually be using the site so that I can have a complete list of group members that includes those 'offline' members. The userprofile nodes that have user records would have a link to the user record, those that don't would not.
-
Future, harder issue: I would like to find a way that all the other modules that use the user record could somehow use my primary user profile instead so that I can include non-user members in those actions. For instance, the signup module signs up users to events, but I would like to signup non-users as well. Don't know how this could be done ... maybe using a method like http://drupal.org/node/32179 to rewrite sqls to use node info instead of user info???
Comments
My goals
Here are mine:
So in a summary: I need the flexibity and power that nodes give me. This is why I want this project to remain as flexible as possile.
http://www.webschuur.com | http://bler.webschuur.com
I really like the possibilties that this opens up.
I really like the possibilties that this opens up.
CiviCRM might give some ideas
I don't think the CiviCRM approach to solving this problem is necessarily a good fit, but you might be able to learn something from CiviCRM profiles.
"I want to be able to designate a specific content type as equivalent to a user record. There should only be one type that has this status so there is no question about which content type is the 'primary' user profile."
CiviCRM takes the approach that the user record is data, not content (and therefore a node). You can expose parts of the CRM record to the user in the same way as drupal profiles by defining the fields in CiviCRM and then creating a "profile" containing the fields you want to expose at registration.
If you want to display CRM data as records, you define the appropriate profile (subset of CRM fields) and expose it as a node via CiviNode (http://drupal.org/node/56661).
"I want to be able to designate additional content types as types that provide additional user information, similar to the role of the profile module now. There could be several of these types for any one user record."
From the single CRM data record, you can define multiple CiviCRM profiles that are subsets of the CRM record. So in this case CiviCRM profiles are esentially these "additional content types" which are 'nodified' by CiviNode.
"I want to be able to link more than one userprofile node to a user record. "
Should be clear from above that this is enabled by the CiviCRM profile approach.
"I want to have userprofile nodes that have no link to a user record for people who do not have an email address or who won't actually be using the site so that I can have a complete list of group members that includes those 'offline' members."
Profiles can also be limited by CiviCRM groups... this would allow you to display membership lists that are include folks who are not Drupal users.
"so that I can include non-user members in those actions"
This is an interesting problem... we have been assuming that you would create drupal users for every offline record in CiviCRM and that would allow you to handle event sign ups. Another way is to rely on the uniqueness of the email address.