Posted by zorbtrauts on September 9, 2010 at 4:01pm
I know joachim has presented Profile2 as a possible foundation for Drupal CRM, but he has also asked whether it will in fact satisfy the use cases.
I think this is an open question, and it is one we need to answer fairly soon. Maybe I've missed it, but I haven't seen any real discussion of this. Should we be building on Profile2? Is it in line with our goals?
I think a big part of the answer here will be based on questions of its flexibility and extensibility. I don't know what the answer here is myself, but I think it is one that we need to address.
Comments
I think the only sensible
I think the only sensible thing is to build on Profile2, from the point of view that we want Drupal sites to be able to extend into DCRM as they grow.
If we end up with one core profile2 module, and then a totally different CRM profile module, we will be in the same sort of mess as with image/imagefield on D5 and 6.
However, the question of is Profile2 in line with our use case is absolutely one that needs to be discussed.
The hard part is that to be a candidate for D8 core, Profile2 needs to be kept fairly slim and simple. To be a good base for DCRM is needs not to make too many assumptions, so modules higher in the stack can easily expand without jumping through code hoops.
Navigating between these two requirements is the tough bit :)
What use cases?
I know what you're getting at: I think we don't yet have enough of a spec to stake a million dollars on Profile2 being exactly the right starting point; yet that in itself shouldn't stop us from developing fundamentals.
Where are the use-case specs? Right now we only have there's just slightly soft-focus notions of where we want to end up. And, in that same soft focus, Profile2 looks like it's pointing in roughly the right direction. It satisfies a number of very low-level requirements and is sufficiently "basic" (not to denigrate the developers working on it!) that where it deviates from a CRM's requirements, we'd have to build that deviation one way or another anyway.
If a module's fundamental enough then it's just a set of bricks, right? We can worry about the plans for the house at the same time as planning for buying in a load of bricks.
I know we could head off on a tangent, but it seems to me that user profiles have been done the same way in Drupal for a long time, and the only major complaint is typically satisfied by moving to Content Profile: which Profile2 is in many ways the more natural successor to than core Profile. Also, the architecture that was initially thrashed out on DC CPH Friday has been taking reasonable shape and, in the absence of specific user journeys to worry about, seems about right.
If we can come up with concrete use cases that point away from Profile2 then I'd definitely be interested in considering an alternative, but let's not hold back basic development - of something which is going to be developed for core anyway - for want of an element of the spec that could be a long time coming.
So specifics... So we're
So specifics...
So we're going to have:
* A standard set of fields we need to implement
* A standard way of representing relationships (contacts and "groups", for lack of a better word NB. the different permutations here contact-contact, contact-group, group-group).
jtsnow pointed out there are some open standards that could be applied to the CRM. Take a look at http://www.oasis-open.org/committees/ciq/ciq.html
I don't know if this is the right standard to implement - if any standard at all... but it might be a good starting point for what we need from Profile2 in order to make a decision on its fate.
CIQ Standards
The link gave you is for v2 of the spec. There is a v3, but I'm not sure if it is finalized: http://docs.oasis-open.org/ciq/v3.0/specs/ciq-specs-v3.html
These standards specify how to represent information (xCIL) for individuals and organizations as well as relationships (xCRL) among them as XML. Whether or not we fully implement the standard may not be important right away. The point I gathered from the xCIL and xCRL standards is that if our data models and APIs reflect the specification, it could save us a lot of time in figuring out how to deal with the various types of information that the system will need to manage.
What this means in terms of implementation is that the system should be aware of the types of fields that exist on contact entities. It's not enough to just have fieldable entities. As an example, imagine that your CRM needs to track the gender of each individual. That's simple enough: You create a text field for your contact entity that stores options for gender.
Now, let's say an external system (whether it's another Drupal module or another piece of software altogether) needs to know the gender of a particular contact. That becomes a problem because, to Drupal, all the text fields on an entity look the same. But if the CRM is aware of the type of information each field holds, then requesting this information becomes easy.
This becomes much more important when it comes to dealing with name, address, ID card numbers, tax numbers, vehicle ID numbers, etc. The xCIL standard gives us a list of what types of information to be aware of and supporting that standard would almost guarantee interoperability with external systems. It also gives us a list of things to support out of the box, even if we only support a subset of what is specified in the standard.
Could the RDF module in D7 --
Could the RDF module in D7 -- or an extension of it -- provide this sort metadata?
The RDF module itself doesn't
The RDF module itself doesn't provide any metadata. Modules can provide mappings between their own data and RDF properties. For example, the node module provides mappings for a node's title, created date, body, uid, and author name.
This allows data to be represented in RDF format, but the module providing the mappings still has to do the work. Using my previous example, the CRM module would have to know text field on an entity should map to a "foaf:gender" RDF property.
Profile2 in core
I'd like to make the case that getting profile2 into D8 core is not a specific goal of the CRM project. Where the CRM requires changes to the profile2 module, and these changes inhibit profile2's chances of being a candidate for core, I believe this is not a concern of the CRM project.
You could conceptualise the 'profile2 in core' movement as an outside influence, and might assert that it has the potential to hold the CRM back. We ought to try to minimise these outside influences, since everyone working on the project is guaranteed to have their own personal agenda ('I want the CRM to do this, but not this, because it fits better with my personal use for it') and the more personal agendas that are allowed to creep into the project, the more chance there is that we will end up building a CRM for the few rather than for the many.
That is not to say that there is not a strong case for profile2 in core for D8. It is merely to say that I believe that case is entirely separate from the CRM project itself.
Profile2's main purpose is to
Profile2's main purpose is to get into core.
If it doesn't, then it can still become a solid contrib module, and that's fine. It does leave Drupal with an awkward problem of still having an outdated Profile module that limps along for yet another major version.
I think it's crucial that we build on something that's widely used and extensible, because a big problem with existing CMS systems on Drupal is the lack of data sharing with other modules: you build something with Profile/Content Profile and Civi and Ubercart and all three systems have stuff about your users and none of them talk to each other.
Risk and benefit of D8 as a core submission
I think that's absolutely true, but it's good to keep it in mind as both a risk and a benefit:
Real-world examples in the spec
Just to follow up on sbroz's original qualms about the CRM project's strategy, I've suggested on this comment http://groups.drupal.org/node/93504#comment-317734 that we try to add as much brainstorming as possible at the bottom of the wiki page here: http://groups.drupal.org/node/92294
Please don't be shy: we need to bridge the "specification gap" with as many real-world examples as possible.