Aller directement à la fin des métadonnées
Aller au début des métadonnées

Multi-site notes

What is multi-site?

I think the first thing to note is that this implementation should be viewed as a Multi-site or multi-domain rather than multi-org. The implementation is based around the idea of several Drupal sites accessing one CiviCRM database. General CiviCRM access is managed through Drupal ACLs so if you don't want a user to have 'access civicrm' on all sites then this is done by Drupal permissions on each site. They don't have a 'cross-site' logon but have a separate user account on each site.

The silo-ing of data is at the contact level. It is in some ways similar to what can be achieve using CiviCRM ACLS except that it affects what is included in aggregates too and dashboards like contribution & participants. If you have access to view a user then you can see all details including contributions, activities but not the groups which they are in on another site. If a user logs onto the

The main areas in which multi-site seems to go beyond normal CiviCRM functionality (with ACLs & nested groups) is with regards to allowing completely different Drupal installs to use the same database with different URLs and different Drupal permissioning systems & drupal config.

Some work has been done on setting membership types to be by site although this didn't appear to have full functionality as you can still see the other site memberships on the contact if the contact was viewable on your site.

The set-up lends itself very well to a head office branch sort of organisation as the functionality is hierarchical. ie. the users of the Head Office site can see all the users from all the sub-sites. Users logged into Branch site 1 cannot see users from Branch site 2 unless they have 'administer multisite'. Likewise users logged into branch 2 cannot see Branch 1 users unless they have the extra drupal permissioning. The Head Office users can see both.

The mechanism behind it is nested groups. The parent site has a 'site group' which is owned by it. All members of this group can be seen from within the parent site. The sub-sites own 'site groups' which are children of the parent group. Because they are in a group which is a child of the parent site group all members of the sub-sites are also members of the parent groups and are visible within the context of the parent site. It is possible for a group to be a child of more than one group in which case it will be considered to be in both those groups and can be seen from the site of both those groups.

It is important to understand that the groups are there to determine which sites you can be seen from not to provide access. It is possible for a group to be a child of a group from one site and belong to another site but this may be unintentional.

Each site group & site is linked to a site master organisation. This appears to be primarily for the purposes of providing extra details for the tokens sent out by CiviMail (e.g. domain address). It may also be for membership purposes but membership types are defined as being 'owned' by a site so it probably isn't required in this context.

The multisite functionality is limited from the perspective of providing services to multiple organisations that are not closely linked. Take for a site providing fund raising services for multiple charities (ideally with a single sign-on for a giver). Each charity would want to see the contributions person A gave them and not the contributions that persongave to another charity. At this stage this isn't supported. A number of sensitive bits of data such as activities are not site specific.

The set-up whereby only one drupal / civicrm database is used is also not supported. If administrator A has access CiviCRM permission and is an administrator of site A they will only see site A contacts. But when they log into site B they will see all of the site B contacts (but not the site A ones).Thus the implementation is about being multi-site rather than supporting multiple organisations within one drupal database.

If someone winds up being in more than one site group (e.g. because they register on more than one site) most of their details(activities, contributions) but not Groups will be visible for users of both sites.


If you add a contact at L2 it is joined to the L2 Parent Group

If you create a user at L2 it is joined to the L2 Parent Group

If you import contacts at L2 they are joined to the L2 Parent Group.




Multisite functionality works on an all or nothing basis for viewing contacts. If you can see the contact then you can see all their contributions/ memberships/etc

I had expected people to be able to share contact information about a contact but only see contributions, registrations etc for their organisation. The current set-up means that it would be of limited use in the context of multiple charities sharing a database.


Memberships  Membership types can belong to a given multi-site org but the flow-on functionality seemed to be limited



Options for Membership types not owned by a given org appear on the membership search page. However the user will not find any members while searching using these options if they don't belong to their organisation

That only those membership types which are owned by that org would be visible


Contribution form will allow a membership type belonging to another org to be included. But if someone signs up they are not automatically added to the other org

I expected that using a contribute form with a membership in another org would cause the person to be added to both orgs (and potentially the contribution amount to show in one & the membership amount in the other??)


L2 site manager cannot create a new membership type because when they search for a membership organisation no results are returned

Would expect it to default to their own org,11608.0.html

L2 site manager can see memberships from other organisations and 'appears' have permission to change which site a membership type belongs to (although this fails per item above)  

Would not expect them to be able to view or edit other org's memberships,11608.0.html





Cannot see membership types from other orgs when adding a new membership

This is as expected. Issue appears fixed

Session Support



When logged into one site of a multisite you need to re-log in when you move to another of the multi-sites

I expected the user experience moving between the sites to be seamless. However, I also thought they were going to run off one Drupal DB which was incorrect











When creating a group logged as the administrator of a multi-site I only saw the options and groups relevant to this site

This is as expected


Import - when importing and adding a contact to groups they are also added to the 'main' group for a given site.

The group created on import was created as a 'child group' of the main site group

Seems reasonable J


Neither the group created via import or directly by the administrator within the L2 site have been associated with an organisation

I guess only the site's 'Master group' is associated with an org & the others are children of it. But I was able to edit a created group to be associated with the relevant org so unclear on the logic here


I was unable to remove the parent from a group without changing it to another parent

I think this is part of the multi-site requirement. The group must be part (directly or indirectly) of the site's main group


I was able to review all groups in the relevant site as the site manager

As expected - issue appears to be resolved

ACL permissions to give users access to view a group from another site do not over-ride the limitations of the multisite. If they have permission to view the treasurers group but it is not part of their site they cannot view members in it .

I had thought that maybe the ACLs would over-ride the multi-site allowing contacts to be viewed across sites


A user without administer multiple organizations permission only sees groups from the org they are logged into. When they click on settings they do not see the parent organisation or the Parent Group

As expected - issue appears to be resolved

Multisite module: hide site parent group from users without administer Multiple Organizations permission

Multi-org: Manage Groups lists all groups and requires administer CiviCRM permission (part 2)

Note item 1 is not multisite specific but appears unresolved:,11571.0.html

When the same user clicks on a group that is a subgroup of the site group they see the option to remove parent but if they do and then save nothing changes and no error is returned. (in this test only 2 groups exist for the L2 site and - the main group & one child)

This seems a little clunky but doesn't break anything. I would have not expected them to see the option if they couldn't do it.


My L2 site level administrator WAS able to disable and delete the L2 site group

I believe this is a bug,11569.0.html

Groups on dashboard

No groups are visible on the user dashboard (civicrm/user?reset=1&id=56) even for users with multi-site permissions,11572.0.html




A state manager without 'view all contacts' or 'administer multi-site' can view contacts in their site

As expected - issue appears to be resolved

Contact sub-types are not site-specific

Seems reasonable - had wondered if that was what this was refering to but guess not


Current employer autofill doesn't seem to work on create new individual for non multisite user



When I create a new contact (with or without multi-site permissions) the new contact is not added to the L1 group

I expected from Dave's post it would be & from the fact that existing contacts seemed to have this but reviewing the SQL none of the contacts previously added through import did so I must have been,11558.msg49665.html#msg49665

Didn't identify any other contact leakage - unsure what this issue refers to (membership aspect addressed separately)








Tags are not site specific

no expectation




Outstanding issue - not reviewed







I can see activities (e.g. Event registration activities) relating to contacts that are in other sites (although I cannot get through to the contact if I click on the link)

Contacts would not be visible (through activity search) if the contact is not visible.


Information from DaveJ about what is applied where

    Relationships    globally
    Groups    local
    Tags    globally
    custom fields    globally
    custom groups    globally    but option to add locally
    activity types    globally
    case types    globally
    gender options    globally
    greeting types     globally
    etc.    globally

# CiviContribute        globally
    contribution types    globally
    payment processor    locally

# CiviPledge        globally
# CiviMail        globally
    components    globally    use tokens locally
    from addresses    locally
# CiviMember        locally
    membership types    locally
    membership status    locally
# CiviEvent        globally
    event types    globally
    participant status    globally
    participant roles    globally
    price sets    locally
# CiviCase        globally
    case types    globally
# CiviGrant        globally
    grant types    locally

global settings
    most things    local
    date formats    local