CiviCRM Community Forums (archive)

Hi,
About a month ago we finally installed multi-site with CiviCRM 3.1.4. The testing went great and things were looking really good. Then we decided to upgrade to 3.2.4, which is what we plan to roll-out to our live sites.
 
After the upgrade the only way we can get “Search” and “Contacts” to show up in the Navigation menu is to enable the permission to “view all contacts”. If we do that, both Search and Contacts show up in the menu but so do all the Contacts for that site.

We have tried the following:
1) followed the multi-org instructions with manual install and auto/manual install
2) made sure to insert the appropriate domain and navigation records for each site (subsite1,subsite2)
3) checked that the multisite module (separate dnld from civicrm) was enabled
4) verified that the permissions for the test users allowed basic functionality except for administer civicrm/view or edit all contacts
5) checked two subsites with test users
 
results:
 
1) "Search box", search menu item, and contacts menu item do not appear in the civicrm nav bar
2) paths exposed by these links are accessible but invisible when browsing
 
to remedy these, we have tried:
 
1) manually setting the menu permissions for each item in the missing areas to 'Access civicrm'
2) deleted from the tables in civicrm_navigation.mysql passing the appropriate domain id parameter
3) importing the civicrm_navigation.mysql file passing the appropriate domain id parameter
4) using /civicrm/admin/menu/rebuild when logged in as an admin user
5) deleting the templates_c directories in the subsites
6) adjusting the permissions in drupal to use everything except administer civicrm/view or edit all contactts
 
Manual Solution
*******************************

1) Manually added 'Search2' and 'Contacts2' entries to the navigation menu and saved
2) Manually moved all of the 'Search' and 'Contacts' child menu items under the new Search2 / Contacts2 entries
3) deleted the 'Search' and 'Contacts' menu entries
4) renamed Search2 / Contacts2 to proper names

If you attempt to set permissions on 'Search' and 'Contacts' menu entries it still does not show up to a non-admin/non-view/edit-all-contacts user.

If you create new menu entries with the same names (e.g. new entry name='Search' or 'Contacts'), the top-level entries do not appear to a non-admin/non-view/edit-all-contacts user.

Questions?
1. Does anyone have the multi-site configuration working successfully with CiviCRM 3.2.x?
2. Does anyone have any suggestions for other things we might try to fix this issue?

Any help appreciated as we are anxious to get the ball rolling with use of multi-site for all our regional offices and chapters.

Thanks,
Cynthia

These menu items still fail to be hooked on login by a user with non-admin/view all contacts permissions.
multisite installation steps:
1. clean installs of Drupal 6.19 for three domains (domain1,domain2,domain3)
2. install civicrm via automated installer on domain1
3. prior to visiting any civicrm pages, modify civicrm.settings.php to set MULTISITE = 1
4. create an organisation for domain 1
5. associate organisation with Default Domain Name group
6. create organisations for domain2, domain3
7. create groups for domain2, domain3 and associate with respective organisations
8. insert rows into civicrm_domain for domain2, domain3
9. import civicrm/sql/civicrm_navigation.mysql with domainid selector in first line modified for domain2, domain3
10. copy domain1/civicrm.settings.php to domain2/, domain2
11. modify civicrm.settings.php in each directory: UF_DSN for domain1, domain2 other site-specific configuration options as appropriate, MULTISITE=1,DOMAIN_ID=civirm_domain.id, org_id=orgid in item 4 above, domain_group _id= groupid from item 7 above.
12. download drupal module multisite from svn
13. enable module, set permissions for authenticated user - access civicrm, add contacts, etc (no view all contacts, no edit all contacts, no administer anything)
14. reported problem persists for auth user, even after menu rebuild as admin or wipe of civicrm_preferences, civicrm_navigation, etc as referenced in civicrm_navigation.mysql
Please advise.

Hello Cynthia,

No, my last post mentioned code lines are not the patch for fix. we already have this code at CRM/Core/BAO/Navigation.php at line around 443
here are those lines

       //we need to check core view/edit or supported acls.
        if ( in_array( $menuName, array( 'Search...', 'Contacts' ) ) ) {
            require_once 'CRM/Core/Permission.php';
            if (!CRM_Core_Permission::giveMeAllACLs( ) ) {
                $skipMenuItems[] = $navID;
                return false;
            }
        }

here logic implies, user could see those navigation links only when user has to have at least one of the below permission
1. Edit All Contacts.
2. View All Contacts.
3. Edit/View particular set of contacts due to some ACL's

So my thought is to debug this function, therefore it would be great if u could put below code at any place

require_once 'CRM/Core/Permission.php';
$allowLinks = CRM_Core_Permission::giveMeAllACLs( );  
CRM_Core_Error::debug( '$allowLinks', $allowLinks );
exit( );

and see the out put, for any user if $allowLink will gives true means those navigation menu get build otherwise given logged in user is not able to see those navigation menus.

One more question, Does given user able to view at least some set of contacts ?

For time being you could suppress permission check from CRM/Core/BAO/Navigation.php line around 444
change below if condition
if ( in_array( $menuName, array( 'Search...', 'Contacts' ) ) ) {to
if ( false && in_array( $menuName, array( 'Search...', 'Contacts' ) ) ) {and rebuild menu.
lets us know if you get these navigation links back.

If your installation is on test machine, I'd like to debug and it would be great if u send me login credential at kiran.jagtap@webaccess.co.in
( I do need both ssh as well as user who is not able to see navigation menu links )

Also I'll setup my local machine in next week or so and get back to you with proper solution.

thanks,
kiran

So, I'm seeing the behaviour Cynthia describes on one child site but not another one. The difference is that one has sub-groups and the other doesn't. Creating a group within the site without any causes $allowlinks to be set to 1 (you correctly predicted it wouldn't be on the site that wasn't working earlier in the thread)

I suspect that the problem is this function: returns child groups but not parent but have not proven it / figured out exactly how it is happening yet

multisite.module

function multisite_civicrm_aclGroup( $type, $contactID, $tableName, &$allGroups, &$currentGroups ) {
    // only process saved search
    if ( $tableName != 'civicrm_saved_search' ) {
        return;
    }
    require_once 'CRM/Core/BAO/Domain.php';
    $groupID       = CRM_Core_BAO_Domain::getGroupId( );
    $currentGroups = _multisite_get_all_child_groups( $groupID, false );
}

Menu rebuild did the rest of the trick.

So adding this

   $currentGroups[] = $groupID  ;

to multisite function seems to fix it but still needs some QA

So much pain for one line!

So - that makes it even worse - it took that much effort to find 5 letters!

Prior to truncating the civicrm_navigation,civicrm_preferences,civicrm_dashboard,civicrm_report_instance,civicrm_mail_settings and reimporting from civicrm_navigation.mysql set specific to each domain, modifying the multisite.module in either way noted above (removing the false parameter or adding the groupid to the array) results in the quick search box displaying for our test user but the navigation items still missing. After truncating and reimporting the .mysql file for each domain, the expected menu items are visible to our non-admin user.

I can also verify that select distinct domain_id from civicrm_menu only returns one row after calling /admin/menu/rebuild - not sure whether the multisite build/install inserts a distinct row to this table per domain (if so, it isn't in the civicrm_navigation.mysql file) or whether it is automatic, if so, knowing exactly the circumstances of the insert would aid in anticipating problems from this potential anomaly.

Regards,

Karl