There's a wiki page about the CRM stack, and I thought it would be valuable to move discussion and clarification here.
I've tried to construct mental maps of the existing specification, to make sure that it's not inconsistent or ambiguous. I've attached the results of a couple of these mental maps below. I don't want to re-hash existing discussions, or insert my own opinions into them in retrospect, but I do want to make sure that the spec has correctly encapsulated the original intention! That way we can develop more closely to an agreed spec and avoid developing something which works but isn't what was expected.
I'll explain how I think it's all meant to happen below. If anyone has access to a brilliant primer on D7 Field API terminology for dummies then do let me know, as I'm currently mired in D6 terminology myself.
Page 1: genera
Please tell me what's wrong with this statement, as encapsulated in the attachment:
A genus is a mixable class (D7: "bundle"?), which can be applied to an existing profile object (D7: "entity"?) and leave the object with extra field instances (D7?). It does not affect the underlying profile type bundle (D7?) The genus does not get applied across all profile objects (D7?) of a particular type, just one particular party's particular profile. Genera are additive: that is, applying two genera leads to the profile instance having the union of the field instances described by the fields on each genus.
More specifically:
- Should a genus apply fields to the profile "content type" (D7: "bundle"?) or just to the specific profile object (D7: "entity"?)
- Can a genus apply fields across several profiles or profile types, saying "I want fields X and Y on the personal information profile, but fields A and B on the membership profile"?
- Are some genera mutually incompatible?
Page 2: parties and users
Again, tell me what's wrong with this statement:
A party is an object (D7: "entity"?) of only one type (so not "content-typed" - D7?) which can have profiles attached to it via a standard entity-entity reference (D7?) The party behaves exactly like a user. If a user exists, the party is replaced by the user--profile core of Profile2 takes over. Users can have typed relations to parties which carry permissions, so a given user can
Again, more specifically:
- Party--party or party--user typed relationships - it strikes me that parties behave a lot like organic groups. You can belong to them if they're organizations, for example. This would be very similar to a low-end CRM solution we recently had to employ with a client, whereby organic groups were indeed used to represent businesses in a directory. Does it make sense to bring D7 Groups into the tech stack?
- Should the party be there instead of a user, or along with it? That is, should the profile_anonymous module only add parties for non-user profile collections, or when enabled should it transplant a party into every existing user--profile relationship, so that you get a nicer symmetry of (optional user)--party--profiles? That transplanting would also help with party--other-user relationships, because there'll always be a party object to treat as an organic group and assign typed relationships to. Basically, you'd always be able to find a party object in a profile collection: the user would end up along for the ride.
Other clarifications
- Is it worth clarifying what's in the stack - the code architecture - and what's part of the model description - the data architecture?
| Attachment | Size |
|---|---|
| Drupal CRM architecture.pdf | 22.83 KB |
| Drupal CRM architecture.odg_.txt | 17.25 KB |
| Drupal CRM architecture v2.pdf | 33.62 KB |
| Drupal CRM architecture v2.odg_.txt | 18.56 KB |
Comments
Following discussion
Following discussion w/Joachim on IRC, here's an updated architecture diagram. Notes to follow on wiki page.
Chucking an idea into the mix
http://ostatus.org/sites/default/files/ostatus-1.0-draft-1-specification...
Looks to me like it has some resonance with work on the CRM.
It has some interesting ideas. Contacts are represented by uri's. Person is one of contact types. It also includes Atom Activities. A way way for activities to be expressed in Atom form. That's interesting because it ties in well with modelling the activities on contacts in a CRM.
It seems to me that if there's existing standards in the area that the elements in the CRM should map onto those standards, so that modules can be built that interact with the standards.
For example - if the CRM is tracking a person, and the person has a Diaspora/Facebook/Linkedin page/site then it would be useful to build a module that grabs and incorporate the info that the person is generating about themselves, their relationships and their activities, as part of the CRM entry for that person.
It's good to have a technical
It's good to have a technical specification to work off, although it doesn't cover the user experience or basic user "can I do?"s. We should also be careful pulling that standard off the shelf, as it includes a lot of baggage about e.g. microblogging, client APIs, publishers and subscribers that while they might have their analogues in a CRM are ultimately different real-life and potentially spec entities.
An actual CRM spec would be good - any research anyone has about actual CRMs, use cases, interviews with potential users etc would be solid gold. Anyone?
Has the discussion of the
Has the discussion of the role of Organic Groups been carried further anywhere else? I think that's an important point to consider.
For example, assuming a generic 'entity_relationships' module, how do we make the relationship between an 'party' and an 'og' useful? Or is that out of our scope?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
OG was just a possible
OG was just a possible solution to the underlying use cases: these in turn came out of the Drupalcon Copenhagen brainstorming, which I missed most of. From what I gleaned from joachim's documentation and discussions, here's some examples of relevant use cases.
Back to a solution... My personal feeling is that I see this being solved by making each party potentially an organic group. So Celia is an OG member of both Initech and the ICW, and with something like OG user roles, she can have different privileges regarding the Initech party, from the ones she has regarding the ICW party.
But if you can think of alternative ways of solving this, then I think the part that OG plays here is still up for grabs. I definitely don't want us to be led by only the solutions I personally know!
Context
I was thinking about this a little more, and it strikes me that context is important.
Amy is an executive in the context of her work
She's a helper in the context of her voluntary work over the weekends
She's got one telephone number in one context, and another in the other.
She has a personal website on Facebook, but also maintains a Linked-in page in the context of her career. She also has a blog on her company site as the CEO. Without knowing the context of each of the sites, or phone numbers, or organizations that she is involved with, the relationship isn't clear.
Your problem with Solomon & Celia is the same - there's more than one context for relationships.
And Celias right to edit is also contextual.
The context could be hardcoded - e.g. a limited set - which company is an employees employer, or context could be configurable in itself, with a standard list as the basic. I'm thinking that there are some basic contexts. Maybe 'owns', 'related to', 'part of', 'subordinate to'.
To me, this just suggests
To me, this just suggests that the "thing that defines relationships between entities" should itself be a fieldable entity. Then integrators can store whatever meta-data they want about the context of relationships.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Absolutely. A relationship is
Absolutely.
A relationship is itself an entity, and has all kind of data on it, including but not limited to what type of relationship it is, when it began, when it will end if at all, and who may alter its status.
I'm very interested in the
I'm very interested in the genus idea. Any development on this?
Not that I know of. Something
Not that I know of.
Something very similar has been suggested for Drupal 8: http://drupal.org/node/100925#comment-4285580
I've suggested on that issue that this could be developed in contrib on D7, but no sign of movement on that yet...
My opinion on most important features
I think the most important parts for a CRM are the following:
People (Organuzations, Relationships)
Invoices (opportunities, offers) - maybe with Ubercart
Contact History (emails, pn, phone calls, sms, visits, ...)
Tasks (with dates)
Files
Campaigns (newsletter,...)
I think a lot can be done with views, rules, vbo, ubercart, cck, taxonomy ...
Profile with features
It's true. This group has been hmming and hawing for a solution for several years, but as Drupal has matured in 6 and 7 it has become clear that packaging it up into a good recipe using a variety of modules is the way to go.
The original intent of this group (from what I recall) was to put together a solution that would allow Drupal to reach into an existing CRM solution to expose its data to a member-based website. Maybe that's still a missing module that could more easily team up with D7's new database abstractions.
Ultimately, if you're going to use Drupal 6 or 7 to build out a web-based CRM, it would be great for us to give some case statements on what the goals were and how the solution came together... then, ideally, roll out a Profile or some Feature sets that the community can pull from for future projects. A team I'm working on at www.rhubarbmedia.ca is close to launching a great D6 CRM solution that I'll be sure to post a case study on in here (or at least link to).