Re: [drupal-devel] CiviCRM, Civicgroups, OG, Profile- Playing together
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.
On 12 May 2005, at 16:43, David Geilhufe wrote:
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).
I'm afraid none of us Drupal developers are familiar with CiviCRM. It is hard to make recommendations without having looked at CiviCRM ... The fact that user profiles don't have a "data model" is an interesting point. How did the FOAF module solve this? I'd think a data model is required to syndicate information between sites. Either way, we're not opposed to patches that make the profile module more extensible/powerful. -- Dries Buytaert :: http://www.buytaert.net/
On Fri, May 13, 2005 at 09:11:27AM +0200, Dries Buytaert wrote:
On 12 May 2005, at 16:43, David Geilhufe wrote:
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).
I'm afraid none of us Drupal developers are familiar with CiviCRM. It is hard to make recommendations without having looked at CiviCRM ... The fact that user profiles don't have a "data model" is an interesting point. How did the FOAF module solve this? I'd think a data model is required to syndicate information between sites. Either way, we're not opposed to patches that make the profile module more extensible/powerful.
FOAF really didn't have an ideal solution to this. Chris Messina had some strong criticism for it: # The FOAF module has the worst possible UI I've ever seen. It doesn't # help you get started, it begins with a dirth of stupid fields that # don't allow you to fix the problem of associating the fields with # contact fields. Why doesn't the software do the association for you?! # # This module is ONE BIG DEAD END! http://civicspacelabs.org/home/node/6939 Now with the location module we can have information about where a user is located stored in a regular place. CiviCRM will be taking advantage of this. One of the main obstacles which we ran into while doing this integration was finding a good place to get the complete user object when any user records are updated. For example, implentations of the insert and update ops remove the data they save from the user object so the CiviCRM module wasn't guaranteed a complete user object. -Neil
On 13-May-05, at 11:08 AM, neil@civicspacelabs.org wrote:
On Fri, May 13, 2005 at 09:11:27AM +0200, Dries Buytaert wrote:
On 12 May 2005, at 16:43, David Geilhufe wrote:
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).
Provide a proposal (patches!) for an improvement to profile module. This gets your hooks into core. You need to work in the context of Drupal.org itself. If you can provide a more powerful replacement for profile module....great! That would seem to be task number one in representing user data, and you can then apply whatever changes you need to support your goals (e.g. APIs, user data that exists separate from accounts, etc.). Are there modules you can put on Drupal.org itself? A modular approach is going to be needed, and you'll need to figure out how they work together.
required to syndicate information between sites. Either way, we're not opposed to patches that make the profile module more extensible/powerful.
How did the FOAF module solve this? I'd think a data model is
FOAF really didn't have an ideal solution to this. Chris Messina had some strong criticism for it:
# The FOAF module has the worst possible UI I've ever seen. It doesn't # help you get started, it begins with a dirth of stupid fields that # don't allow you to fix the problem of associating the fields with # contact fields. Why doesn't the software do the association for you?! # # This module is ONE BIG DEAD END! http://civicspacelabs.org/home/node/6939
Excellent criticism...with no suggestions on how to fix this. We (Bryght) ship profile + FOAF pre-configured, so it "just works". It is "solved" by a mapping interface between defined profile fields and the standard set of FOAFnet fields. Of course, core Drupal ships with profile empty, which means it takes a while to configure. I think we had discussed this a while back...shipping profile with a set of pre-defined, standard fields. -- Boris Mann http://www.bmannconsulting.com
Excellent criticism...with no suggestions on how to fix this.
We (Bryght) ship profile + FOAF pre-configured, so it "just works". It is "solved" by a mapping interface between defined profile fields and the standard set of FOAFnet fields. Of course, core Drupal ships with profile empty, which means it takes a while to configure. I think we had discussed this a while back...shipping profile with a set of pre-defined, standard fields.
Thank you for providing a viable solution to improving the situation. I'll work to see what we can do to have this better configured out of the box in our next release, as well as write documentation to help others use it correctly. Kieran
-- Boris Mann http://www.bmannconsulting.com
On Fri, May 13, 2005 at 12:40:26PM -0700, Boris Mann wrote:
On 13-May-05, at 11:08 AM, neil@civicspacelabs.org wrote:
On Fri, May 13, 2005 at 09:11:27AM +0200, Dries Buytaert wrote: FOAF really didn't have an ideal solution to this. Chris Messina had some strong criticism for it:
# The FOAF module has the worst possible UI I've ever seen. It doesn't # help you get started, it begins with a dirth of stupid fields that # don't allow you to fix the problem of associating the fields with # contact fields. Why doesn't the software do the association for you?! # # This module is ONE BIG DEAD END! http://civicspacelabs.org/home/node/6939
Excellent criticism...with no suggestions on how to fix this.
We (Bryght) ship profile + FOAF pre-configured, so it "just works". It is "solved" by a mapping interface between defined profile fields and the standard set of FOAFnet fields. Of course, core Drupal ships with profile empty, which means it takes a while to configure. I think we had discussed this a while back...shipping profile with a set of pre-defined, standard fields.
This is an excellent way to make these modules work together. With location module we have a consistent place for locative data which is more dependable than the profile module. -Neil
participants (5)
-
Boris Mann -
David Geilhufe -
Dries Buytaert -
Kieran Lal -
neil＠civicspacelabs.org