As I mentioned at the DrupalCRM BOF yesterday, there are things you can help with right now with code!
All of these are vital components to the future Drupal CRM as building blocks.
Here's the list:
-
Profile 2
http://drupal.org/project/profile2
This is the foundation stone of CRM. It's a port of Core D6 profile module to D7 FieldAPI. It's nearly ready, but there's a few issues open that need your help. Also, this needs people to try this and think about whether it satisfied our use case. -
Profile Contacts
This doesn't exist as a project yet, but it's here: http://drupal.org/node/893032
This is the first stone on top of the foundation ;)
Go read the spec! Make suggestions! Complain about the name, otherwise I will register this as a project page very shortly for us to start collaborating on the code. -
Address field
http://drupal.org/project/addressfield
A Drupal 7 field module to hold postal addresses, implementing a subset of the xNAL standard.
A key element of CRM. Needs your help!
See also the old thread on Profile2 roadmap and architecture: http://drupal.org/node/623210
Comments
Contact Importer module
This looks to me like a project it is worth looking into porting and including in this work:
http://drupal.org/project/contact_importer
Interfacing, above and below
At the lower architecture levels, a module with basic hooks to enable e.g. VCard conversion might be worthwhile sooner rather than later, to tie in with Profile2 development. Although from what you say on the profile_anonymous thread at http://drupal.org/node/893032 , I gather that Profile2's structure is itself basically tied to a D8 core path. Is there any flexibility there?
Is it worth thinking about basic interfaces now rather than later? Are we in danger of building something quite complex to set up and maintain otherwise, with the genera and parties? It would be nice to have CRM use-case interfaces easily separable, so they don't weigh down Profile2. Also, it would mean that new interfaces could be rolled if there's a more usable way to do it in the future.
Profile2's roadmap is very
Profile2's roadmap is very definitely to become a replacement for Core Profile in D8, and as such it needs to be pretty slim. Getting new features into it is going to be a tough sell. It's feasible, though, as Core Profile hasn't had any new features at all since D5 at least, but we'd need to really show a need for it. I didn't manage to convince fago of the need to support multiple profiles of one type per user, because most out of the box cases won't need it -- but on the other hand, DrupalCommerce have yet to decide whether they need this and I don't know if CRM does either.
Apart from this one thing with multiple profiles which I think is going to be a bit ugly to build on top, everything else can sit on top of the slim base provided by Profile2.
Things like VCard are likely just complex view modes of a party, I reckon. That's assuming a view mode can supply a downloadable file, but I see no reason why not. Or they could even be a View. Then again, looking at the vCard spec, it looks like the RDF module might offer useful approaches.
Yes, but these are reusable components with a wider scope than CRM. That means more users and more developers, which can only be a good thing.
Also, as we saw in the BoF, the use cases and needs for a CRM range far and wide. An out of the box system like Civi all too often just doesn't suit. The plan is to have a flexible framework which can build almost anything, on top of which we create distro modules or feature modules which create a starter CMS geared towards a particular use case, eg school, charity, small company, etc -- these will all need different genera.
Yeah, I'm happy with the
Yeah, I'm happy with the extra complexity generally - and it's bound to arise as we build reusable components - but we do need a UX which takes care of the most common tasks through dashboarding rather than having to build and apply generas from the ground up. I was just wondering out loud whether UX building should come sooner in terms of specific modules, rather than applying it at the very end as a gloss.