From our perspective (David, Lobo and Dave-CiviCRM team), and of CivicSpace, we would like to see as deep and wide integration of CiviCRM into CivicSpace/Drupal as possible.
For those that are unfamiliar with CiviCRM, it provides a CRM repository tailored to the needs of non-profits, but relevant to other applications as well. It stores contacts, relationships, groups, and actions. It's API could be used to store CRM data for a volunteer management module, for example, or data on attendees for an events module. In our discussions with CivicSpace, the intention is that CiviCRM will become part of the CivicSpace release in 0.8.2. I'll let the CivicSpace guys define exactly what this means in roadmap terms. This suggests some immediate priorities: (1) Developers/people need to work with CiviCRM code and sandbox. (2) We need further discussion and ideally some consensus regarding interfaces and division of functionality between CiviCRM and the Drupal core modules which currently handle info about people. (3) Module developers should begin the porting/integration process. ************************************ CiviCRM Code and Repository http://sandbox.openngo.org/crm/ ************************************ Please visit the sandbox. Right now, you can download the code and get it fired up locally per the installation instructions (link at the sandbox site). Today, feel free to contribute workflow suggestions or other high level anlysis. Latter this week, we will be accepting bug reports on the 0.1 release. Our development team is still in the end stages of a feature freeze, so we are actively testing and fixing, but your contributions are INVALUABLE! ************************************ Drupal Core ************************************ Folks out in Drupal land- CiviCRM isn't just useful for CivicSpace applications. You might want to look at it to store sophistocated CRM data. But as Jason has said, there needs to be more discussion on how CiviCRM will interface with Drupal core modules like User and Profile. Our current plan is to implement user hooks which will keep CiviCRM contact data synchronized with Drupal 'users'. However, the best approach(es) for playing with Profile are less obvious. Do we duplicate and/or sync Profile data? This implies a tool for mapping Profile to CiviCRM fields since Profile doesn't have a 'known' data model. Or does it make sense for CiviCRM to "take over" the Profile functionality if it's installed? (We tend toword the latter approach to keep the model cleaner and provide the opportunity for deeper integration to a shared data model). We would love to get this discussion and decisions going anywhere it might be appropriate (drupal-dev, cs-dev, crm-dev). ************************************ Module Developers & Porting ************************************ The 0.1 API and feature set is fairly stable and it is a great time for module developers to start figuring out how to port their modules to using CiviCRM. It is critical to us to support module developers in the porting process. People should feel free to ask for API support on the CiviCRM development email list http://lists.objectledge.net/mailman/listinfo/crm-dev Module developers should also feel free to ask for (and contribute) API and data model changes. One of the big goals for CiviCRM is to help you build better, more powerful applications. The more people that begin the process now, the sooner CiviCRM can be deeply and widely integrated with CivicSpace/ Drupal. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Geilhufe CEO Social Source Foundation david -AT- socialsourcefoundation -DOT- org http://www.socialsourcefoundation.org/ Add me to your address book... <https://www.plaxo.com/add_me?u=34359748358&v0=19951&k0=-658465201> Connect with me on Linkedin... <http://www.linkedin.com/>
On 5/8/05, jasonwhat <jasonwhat@gmail.com> wrote:
http://drupal.org/node/21940#comment-38421 In this post I talk about some of the various modules out there that let users create data about themselves, data on other users, and relationships. What seems clear to me is there is development going on in CS and >Drupal and Civicgroups of several similar user managemnt and organanization tools.
I brought this issue up here http://civicspacelabs.org/home/node/12285 and realize that maybe the CivicCRM is the to omnipotent api that will unify all several modules. If I'm correct, the CivicCRM won't just have it's own data fields, like the current contact module in CS, but will share with modules like profile once they are updated to work with it.
If CivicCRM seems like the place to unify all this then I think there needs to be a more visible way to get these module maintainers and developers involved now. I do believe there is a mailing list for this, but I mean a more visible acceptance from developers that the CivicCRM is what they should be looking towards, and coding towards as much as that is possible.
I might be stating the obvious here, but my fear is that modules like "contact directory" http://drupal.org/node/15863 will continue to be developed duplicating the fothcoming CivicCRM. Or maybe the module is great and will ultimately be an important aspect of the CRM, but if so it would nice to have that conversation started now, rather than later. With all the posts about extending profile, or >searching profiles, referrals and invites, and organic >grouping, it would be nice for these developers to >join in the CivicCRM discussion and development, >rather than starting their own.
I see that CivicCRM was discussed at FOSDEM, but I don't know if a more general "user management" discussion has taken place or not. I'm not sure if it >needs to, but just throwing these thoughts out to the >wolves.