CiviCRM Community Forums (archive)

Is CiviCRM 2.0.7 compatible with prefixed drupal tables?

When I try to synchronize contacts with drupal users, I get an error ... civicrm cant find the "users" table.

IN my case, the table is grhc_users.

I have found references to the fix in CiviCRM 1.8 for this... An added section in the civicrm.settings.php file ...

****reference to a sample civcrm 1.8 settings file below**************

/**
 * Content Management System (CMS) User Table-name:
 *
 * Update the CIVICRM_UF_USERSTABLENAME if needed to match the name of the table
 * where the CMS user data is stored. Default for Drupal installs is 'users'.
 * If you are using table-prefixing for the users table, you must enter the tablename
 * with the prefix. Default table name for Joomla - 'jos_users'. For Mambo - 'mos_users'.
 */

define( 'CIVICRM_UF_USERSTABLENAME', 'users' );

Does this technique still exist/valid for CiviCRM 2.0.7?  I have looked in the database and there is no civicrm_uf_userstablename table.  Is there an installation option I missed that would have created one?

Any ideas? Workarounds?

Thanks.

You can set the users table name here: http://drupal.demo.civicrm.org/civicrm/admin/setting/uf?reset=1

lobo

Thanks so much lobo!

totally hadn't occurred to me to do it the "easy" way...

The synchronization worked, but still one problem.  The first name and last name (drupal username) came in as the email address.  That is, the email address was duplicated in CiviCRM as both the name and email address.  My usernames in drupal are all of the form Firstname Lastname ... exactly as shown with a space in between the names.  is this a problem for CiviCRM?

Is there a mapping somewhere for the sync function.  I have seen the import/export mapping, but they dont seem to be appropriate.

Thanks for the quick response.  Youre awesome.

Wow!  Knowing that will save (or consume...) a lot of time.  Thankyou.

I'm curious.  Is this by design for some reason? ... are other things easily broken by incorporating a mapping?  I'm asking because, from a naive perspective, usernames seem to be the most basic usecase for needing CiviCRM in the first place.  Why would someone take the trouble to synchronize/integrate drupal with CiviCRM if they didn't want the ability to track, group, communicate with, and manage individuals and groups by name?

thanks lobo,

I'm gathering from the clarity and simplicity of your answers that you've been with this for a while. do you have any idea from your experience with other drupal users how they have managed this challenge in practice?  Do they just communicate with their constituency by email name? Or do they all need to get down and dirty hacking the code and then maintaining the hacks through future upgrade paths?

Are there approaches that have really worked for people?

Thankyou.

This looks like what I or my users would essentially do with a standalone instance of CiviCRM. 
If I am understanding this, a user who followed the profile instructions would have to repeat that in my drupal site. Or if they had already done this in the drupal site, filling out CiviCRM profiles might seem an unwanted chore.

My question was really more about whether there were effective methods that people were using to get drupal and CiviCRM to work in a complimentary way with each other ... if the totally automated version was not happening until 2.1.2.

As far as I can tell to this point, it seems that there is effectively no real exchange supported between the two packages except for a drupal user export ---> civicrm import. 

0) am I right or am I still missing something?

1) Did pre 2.1.2 users have any methods/workflow practices that made drupal/og and civicrm function in an integrated or semi-integrated way?  Or did they simply use the packages side by side?

2) Is it possible that whoever wrote (or participated) in the civicrm_og_sync.module might consider bidding on just doing the bug fix that would allow drupal 5.x users the sync functionality?  If the work was not large ... especially if any of the experience/code integrating it in 2.1.2 would be useful ... maybe the price might not be high.

3) How does one contact the developer/s in this community?


thanks

thanks.

I appreciate your reticence to support older versions and the limitations on your time.  The drupal community supports the current version and 1 (one) previous version.  For me and others there this has been essential since the lack of modules fully ported to version 6.x prevents me from migrating. (and taking advantage of CiviCRM 2.1.2).  I imagine something similar will happen for many at the v6.x to v7.x transition in the future.

I had tried the profile injection, and it did seem to be the best thing I could find.

This only works "going forward" and only partially.  drupal also uses addresses for mapping, views, etc.  Addng a profile form to drupals registration solves a problem with getting the info into CiviCRM but not the usecases that the drupal site was designed for.  a user in drupal who fills out the injected profile form during registration will have no way of knowing that his drupal information is not complete until communicating with a drupal site admin about why some expected funcationality on the drupal site is not there.  Unless there is some custom worded caution note option on the form reminding the user to also fill out his/her info in the drupal profile dissatisfied users will be inevitable.

Also, the groups synchrozation only seems to happen on first install.  I havent found any admin to perform a repeat when new groups are created.  Am I missing something or is this simply the state of the version I am using.

I hope some of what I am seeing/experiencing may help you define/refine your usecases for future tighter integration.  I don't mean to be arrogant - I'm sure that you must already have considered roadmaps for this.

I think I am beginning to understand the fundamental difference in perspective that is generating these issues (for me and seemingly for others)

The integration of CiviCRM and Drupal (strictly as a CMS) makes enormous sense to me and I understand its value and power. Perhaps this has been the primary historical usecase for the integration of these two packages.

The problem comes when Drupal is viewed/used not just as a CMS, but as a community venue.  In this case, the richness and importance of user profile information is needed and used intensively to provide a variety of services to users.  Not just content.  Because of this, keeping drupal and civicrm synchronized for users would require not just the synchronized existance of users, but also a variety of other data, like location and personal profile info, group affiliation, general roles, group based roles, etc.  All or at least many of the same issues arise for information about groups and the consequences of not sharing it successfully.

Clearly defining the uses/usecased intended for the 1) side-by-side, 2) integrated, or 3) truely synchronized functioning of the two packages seems to be really essential. It seems that this could be generically handled by an administrator selectable table mapping much like the column mapping you do for imported text file data.