My organization uses the CiviCRM package to manage our contact database. CiviCRM maintains its own fields relating to "contacts" who may have corresponding user records in the Drupal user table. CiviCRM can insert these fields into the user profile edit page, or reserve them for admin editing only. They do not interact with the profile.module-supplied fields at all.
We wanted to be able to map these CiviCRM profile fields to LDAP attributes, which required editing this module. I've developed some code (see the enclosed patch) that will make these fields available to map in addition to profile.module fields and the built-in fields (mail, signature, password).
To the best of my knowledge, the behavior of the ldapdata module should remain unchanged after applying the patch if you don't have CiviCRM installed. If you do have CiviCRM profile fields, you can map them to LDAP attributes. Both public (available for users to edit in their own profile page) and private (for admins to edit in the back end only) fields can be mapped, and changes are mapped back and forth on user and admin edits of CiviCRM profiles, and user login.
I don't know whether and to what extent the maintainers of this module are familiar with CiviCRM, but it would be great if this were included in future releases. Any comments/questions are more than welcome.
Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | ldap_civicrm_v2-1.patch | 6.87 KB | mcarbone |
| #3 | ldap_civicrm_v2.patch | 4.54 KB | mcarbone |
| #1 | ldapdata_civicrm_v2.patch | 5 KB | xmattus |
| ldapdata_civicrm.patch | 4.95 KB | xmattus |
Comments
Comment #1
xmattus commentedWhoops,
Here's a slightly revised patch which is more in line with Drupal coding standards. Please use this instead of the one in my original post.
Comment #2
xmattus commentedI think this patch could be done a bit better with the CiviCRM v2 API. Has anyone used this or is anyone interested in seeing it upgraded to v2?
Comment #3
mcarbone commentedHere is a version of the patch that uses the v2 API where possible.
Comment #4
mcarbone commentedFixed bug overwriting admin's profile data if editing another user's profile.
Comment #5
dstryr99 commentedHas this been ported to Drupal 6 by chance?
Comment #6
johnbarclay commentedThis should be worked in as a separate module using the user module hooks. ldapauth should make sure to pass the user's ldap entry along in the appropriate hook. The module could be something like civicrm_user_data and respond with data from ldap, cas, etc. in a similar way.
Otherwise the ldapauth (drupal 6) and ldap_authentication (drupal 7) will just get bloated.
Comment #7
scarer commentedI would be interested in this module. Are you going to start work on it?
Comment #8
johnbarclay commentedNo. I don't expect to much at all with ldap_integration except small patches and bug fixes. I'm just trying to keep the issue queue in motion so people with patches can get them reviewed and applied. My main work is on the drupal 7 ldap module.
There really shouldn't be an ldap <-> civicrm profile module. There should be an ldap <-> profile and a profile <> civicrm. With that model, there would be a need for a special module for every module that integrates with ldap. I think feeds module would be the ideal broker between civicrm and ldap for both in drupal 6 and 7.
Comment #9
scarer commentedso is this patch the only current option for using LDAP data to populate civicrm fields?
Comment #10
cgmonroe commentedMarking this old issue as "Won't fix" unless someone wants to supply it as a module. Note: New dev has more hooks and ways to tie into ldap from other modules.