I think #394720: Migrate profile module data to field API has major implications for CRM on Drupal!
Basically, if profiles are entities separate from users, that are fieldable, we pretty much have the core of a CRM already there.
What this module would need to do would be provide a ton of default fields, or ways of adding sets of fields for various things, and an API for collecting that data in various place (like CiviCRM's profile system which does my head in every time).
The other major component is what I call user events tracking -- member was contacted, member opened email, member made donation.
I think for that, CRM needs to maintain its own data as well as pull it in from other sources, eg Ubercart.
Some modules might want to submit their events to us to log, while some like UC maintain their own data, which we'd only pull in when we produce output. So a double API, basically -- modules can either log with us or just give us results.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
matt2000 commentedIt's been proposed in this thread a few things that help to delineate responsibility:
1.) Profile 2 provides an interface for user profiles.
2.) CRM provides an interface for non-user profiles (aka, CRM Contact entities)
3.) Drupal Commerce provides Customer specific field requirements, which can be mapped to any existing field meeting those requirements, or created as new FieldAPI fields and attached to any give entity. The Default might be the user entity.
If it's acceptable to move forward on these assumptions, I think profile2 & entity module are stable enough (though not "stable") to begin work on the entity definitions, UIs, and entity-matching processes that CRM module will need.
Comment #2
avpadernoComment #3
bluegeek9 commented