Why do we need a separate "Party" entity?
The proposed CRM architecture http://groups.drupal.org/node/89779 states :
P-a-r-t-why? Because we gotta!
There's only one type of party bundle, and it just acts as a bridge between a potentially non-existent user and a collection of profiles. Note that the party is always present, even if there's also a user. This helps us because then the CRM only needs to worry about parties and profiles, and not about a heterogeneous mix of parties-and-profiles and users-and-profiles.
I am building an intranet application right now (in D7), and am in need of a "people managing" architecture, where people are recognized as entities, with name, address, ect fields, but not all people will have login accounts. After thinking for days about a solid and flexible solution, I find myself stuck on the idea that Drupal's User entity alone is the best candidate for a basic "person" entity. If the bigest (and only?) reason to have a separate "party" entity is because not every person (in the CRM) needs or should have a "login account", then why not just make the "account info" fields optional on the user entity? By using hook_user_register_form_alter() and hook_profile_form_alter(), I am working on getting the "account status" checkbox to trigger ajax loading and unloading of the account username, password, email, ect... fields. If the user is "blocked" (or inactive) then the account info (and validation) is removed from the form. It's a bit rough right now, but I think using the drupal User entity as a basic person entity is the way to go.
The idea is that the core Drupal User entity is already the de-facto "people" management tool for a Drupal site. With a little modification (just repurposing existing architecture and tweaking UI) this could be a feasible alternative to having yet another abstract architectural element for developers and site maintainers to comprehend.
We are not the only ones in need of a "managing people who might be users, but not always" feature. Drupal Commerce people are thinking about it http://www.drupalcommerce.org/node/148. And I'm sure others are as well. The only thing all these modules have in common is Drupal Core. If Profile2 is really gonna be in D8 core, then we have that and the user entity to work with for maximum compatibility. I strongly suggest going the extra mile, in designing this CRM architecture, to use take full advantage of existing (or proposed) core modules and architectures.
Thoughts?
Comments
Not looking at this from a
Not looking at this from a point of view of code but from a point of view of feature set, how are we going to track entities like a business using only Profile2 and can this be done in a clean UI. We are not only tracking people with a CRM.
We also need to consider that something like commerce is looking to have users and simple data about those users and their transactions. I would think that the data that users are producing in a CRM is going to be far "bigger" and more interdependent on other information.
Does this have any impact on the ability for users to be able to attach a new Drupal user or not depending on settings by the site admin if they create an account. For example we have users in our CRM that we may some day want to have Drupal user accounts. In the event that I let users create their own account it should link up their CRM data. However, I could see times when this would not be the case.
Our goal must be to build a flexible system that takes into account our cases as we are building it but also looks at how others will use it to be able to create a viable eco-system.
-Steve
Owner and Lead Consultant
Denver DataMan
why not just make the
That's an interesting idea!! It certainly warrants exploration, but I fear that too many parts of core -- not to mention contrib -- rely on assumption about what a user object is and how it behaves.