CiviCRM Community Forums (archive)

1.) Yes, that would be an obvious first step toward making something useful for non-programmer end users. I'm more interested in building a toolkit for Drupal developers. Once that's in place, a Feature that deos what you suggest would be trivial, so it's not really much of a middle-ground step, though I guess we could skip some UI work.

2.) No. IIRC (I'm not looking at the code right now), the proof-of-concept should cause the node to display the contact data for the user who created the node. So each user would have their own node. It's like a civicrm-based alternative to Node Profile module. Either way, the concept is not limited to any kind of Singleton usage. My next step would be to implement the ability to associate a node with any given contact. At that point, Nodes & Views would replace CiviCRM Profiles for building Public Directories and search interfaces.

3.) No, civicrm_bio uses nodes because it's the most obvious kind of demo, but the Field Storage engine makes no assumptions about entities. You could already use this same code to add Contact Fields to any Entity, e.g., Users, Taxonomy Terms, or your own custom entity. However, I suspect most uses cases will want to use Nodes anyway, because it has the most potential modules for adding functionality currently, and a good, mature  security model for access control via other modules or relatively simple code.

4.) Good for who? In a week or two (maybe 3 or 4 weekends for me), it could be solid for most CiviCRM data for use by Drupal developers who want to use CiviCRM fields in Entities without having to use any CiviCRM APIs. That could probably also include some basic UIs for point-and-click users, but in order to get something as complete & flexible as Webform CiviCRM, we're probably looking at 100-200 hours, which means early to mid 2013 if I'm doing it myself on the weekends. With $10-20k, I could probably hire a Jr. Developer to help me get it done by December, probably including a module to provide the out-of-the-box content types you suggest in #1.

Anyway, if anyone does want to sponsor, before I take anyone's money, I will develop a full written spec and guarantee delivery of a minimal set of features from that spec. (i.e, the spec might include some 'nice to have' but not promised features. But the promised features WILL be delivered.) But I also want to be clear that I'm not committing to on-going support & maintenance. If the module ends up being incompatible with CiviCRM 5.0 or whatever, it will be up to someone else to upgrade it or sponsor the upgrade.

 Great concept... recently I worked on a project that intergrated drupal nodes with civicrm contacts.  I ended up using contemplate module which allowed me to pull in fields from drupal and civi using the API.  I used Contact Reference to link the node to its corresponding civi contact.

Its not ideal... the process of creating a new entity requires creating a node in drupal, a contact in civi, and then cross referencing them using the ccontact reference (in drupal) and a custom field in civi (a link to the drupal node allowing for civicrm views lists to link back to drupal nodes).

http://forum.civicrm.org/index.php/topic,23560.msg99250.html#msg99250