Aller directement à la fin des métadonnées
Aller au début des métadonnées
Vous regardez une version antérieure (v. /confluence/display/CRMDOC/Multisites%2C+Multidomain%2C+and+Multilevel+ACLs) de cette page. afficher les différences ·  afficher l'historique de la page

What is multi-site?

CiviCRM has built in support for multisite access - several separate sites accessing the same CiviCRM database. (this is different to the Drupal concept which means shared codebase). In most cases a site will be defined by a distinct URL

These sites could be part of a drupal 'domain module' install - hosted within the same database - or be in separate databases sharing a user table or indeed but in dissimilar databases - e.g. drupal 6 &  drupal 7 multisites are in production & this can be a good migration technique. A user may have different permissions depending on which site they log onto. The separate sites have some functional separation - payment processors, membership types & various settings can differ.

Contacts are automatically added to the group for the site they are created on

Multisite extension is the permissioning delivered by the multisite extension on top of this. The extension also helps manage a shared user table (even if you turn permissioning off by setting domain group to 0)

 

Multilevel permissioning behaviour

This permissioning is delivered by the the multisite extension

Multilevel permissioning  lends itself very well to a head office branch or chapter organisation as the functionality is hierarchical. 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 OR shared group organisation (you can mix these approaches but the second performs better). The parent site does not require a site group as it is unrestricted. The sub-sites have defined 'site groups'.  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.

If the multilevel permissioning module is enabled:

  • Contacts with 'view all contacts', 'edit all contacts' will continue to see all contacts
  • Other contacts with the 'civicrm view all contacts in domain' permission will be able to see all the contacts in the site group they are logged onto and it's child groups. (this second point is the source of some difficulty performance wise. This is discussed further in the multisites component document below and in Proposed changes to multisite )
  • The silo-ing of data is at the contact level. It is similar to what can be achieve using CiviCRM ACLS.
  • If you have access to view a user then you can see all details including contributions, activities.
  • If someone register or is added on more than one site then that will expose all their activities to both sites
  • Contacts can only see the groups which are children of their site group unless they have 'administer multiple organizations' permission

  • 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 .

  • All groups should have a parent group

     

    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

     

    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 person gave to another charity. At this stage this isn't supported. A number of sensitive bits of data such as activities are not site specific

Multisite versus Settings Management

Since 4.1 it has been possible to manage having different urls & other settings per site by over-riding settings (those which are stored in civicrm_settings.php) in the civicrm.settings.php file

Setting overrides can handle

  •  different urls
  • different directories
  • different WysiWIG editors
  • different search options

 

Use different domains if you want

- domain specific membership types

- domain specific payment processors

- domain specific different from addresses from CiviMails

- domain specific link back URLS in CiviMails

- domain specific domain contact details

 

Components of multisite functionality

Functionality

Delivered by

Setting

Comments

Issues

 

 

 

 

 

Various settings, urls can be domain specific,

CiviCRM Core - Settings table

This can be configured by domain or overridden at runtime in the civicrm.settings.php file - the latter is a good approach when only settings are dependent on the domain being accessed as it is simpler

Works well in general.

 

payment processors are domain specificCiviCRM Core

Based on domain_id in payment processor table

Domain_id set in civicrm.settings.php

 
Domain contact details are domain specificCiviCRM CoreBased on the contact_id in the civicrm_domain table  

Navigation is domain specific

CiviCRM Core

Domain_id set in civicrm.settings.php

Works well except for WRT upgrades

A couple of upgrade issues are open on this

Reports are Domain specific

CiviCRM Core

Domain_id set in civicrm.settings.php

Works well in general

Upgrades are hit & miss on whether they update these correctly

Group Organization field is exposed

CiviCRM Core Multisite functionality

Domain_id set in civicrm.settings.php

 

 

Multisite

 is_enabled is set to 1

Works fine, allows group to be set

 

Group can be linked to multiple orgs in the schema but only single in the UI

 

Contact is added to the group associated with the domain they are created on

CiviCRM Core Multisite functionality

Domain_id set in civicrm.settings.php

 

multisite domain group is specified

 

 

Multisite

 is_enabled is set to 1

Works well  in general

 

 

Pete has identified that contacts created via current employer mechanism aren’t always added

Parent ID is compulsory for any group created

 

This is implemented in 2 ways.

 

People with the permission to ‘administer multiple organisations’ can choose the parents

 

For others the parent will automatically be set to the domain group of the site it is created on

CiviCRM Core Multisite functionality - note that the parent ID OR the organisational contact_id is required in the latest version of the extension

Domain_id set in civicrm.settings.php

 

multisite domain group is specified

 

multisite is_enabled is set to 1

There are 3 possible scenarios for these nested groups

1)      The child group is a non-smart group and only contains contacts also in the parent group. In this case the nesting will have no effect on the membership of the parent group

2)      The child group is a non-smart group and contains contacts (intentionally or otherwise) not in the child group. The parent group is extended to include these contacts (not hard-added). Contacts added to this type of group extend the ACL visibility for those permitted to see this group

 

3)      Child group is a smart group. Child group criteria extend the parent group. However this extended group is restricted by ACLs. Hence smart groups do not extend any ACLs that apply to the parent group (in core or in code)

This group nesting is problematic as it creates a large load in terms of creating the group_contact_cache entries of 2-3 levels of parent groups and resolving the smart group cache. Using the latest version of the extension & using group organisation for linkages will mitigate this. You can still use the hierarchical approach where you want to build up a hierarchical group for other purposes (e.g. mailing)

 

Changes to groups frequently cause time outs & server load as the group cache is rebuilt for the parent group – inclusive of resolving every child smart group.

 

 

Parent group is optional IF group organisation is set

Multisite dev version of extension introduces this

https://github.com/eileenmcnaughton/org.civicrm.multisite
   

Contacts without ‘view all contacts’ permission but with ‘view all contacts in site’ are allowed to see all contacts in the domain group

CiviCRM multisite extension

Domain_id set in civicrm.settings.php

 

multisite is_enabled is set to 1

 

multisite domain group is specified

 

ACL_is_enabled is set to 1

Permission is based on hard-adds to the domain group. WRT the 3 scenarios above

1)      The addition of contacts to both parent and child groups is redundant

2)      Hard adds to child groups extend the parent group and are useful where this is the intention (e.g. a child group that represents a sub-site.

3)      Smart groups. Smart groups are cached in their entirety, both for the smart group and any parents it may have. This creates a lot of work. However, on their way out they are filtered according to the previous 2 items.

From a contact viewing permissioning point of view this suggests that only where #2 applies the group nesting is useful.

 

As an aside  - the multisite extension currently works on an either or basis with other ACL hooks. Hence a contact can either view all contacts in domain OR have other code based ACLs applied.  Some thought should go into desired behaviour when both are in use

Contacts without ‘view all contacts’ permission but with ‘view all contacts in site’ are allowed to see all groups within the site

CiviCRM multisite extension

Domain_id set in civicrm.settings.php

 

multisite domain group is specified

 

 

multisite is_enabled is set to 1

 

ACL_is_enabled is set to 1

This is currently tied with the group nesting & those groups that are children of the site group are visible. However, as seen above the nesting mechanism should only be used for child groups where it is desirable for hard-adds to that group that are not otherwise part of the domain be included in the parent group – ie. it should be used carefully & deliberately

 

Potential replacement mechanisms are group_organization & group_type.

 

Either of these could be used to designate which domains a group should be visible on & either from a schema point of view support many to one, from a UI group_organization only supports one-to-one

 

Potentially people with ‘administer multiple organisations’ could create global smart groups & specify which sites they appear on.

 

Those on sub-sites with administer civicrm could specify if the group is available on child sites.

 

 

See Proposed changes to multisite

There is a general problem in that the civicm ACLGroup hook is inconsistently applied in core – see

http://issues.civicrm.org/jira/browse/CRM-12209

Shared User Table handling

Multisite extension

Extension enabled

UF_matches are updated where the user name name is the same on multiple domains. The multisite extension will manage this when enabled even when multisite & acls are turned off

 


Functional Separation in Multisite

Entity
Is separated
Notes
  
     

Contacts

 

NoHOWEVER, the multilevel 'multisite' module adds ACLs that do provide segregation  

 contact related entities-

activities

address, phone etc

contribution

pledge

participants

case

personal contribution page

relationship

No

 

 

The multisite concept only limits access to this data by ACLs - one implementation is the 'multisite' Multilevel module.

 

  
grantPossiblysee notes with option value  
membership type

yes

 

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

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

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) 

 

 

 
membershipno


  
membership statusnoit would be more generally useful for this to be by membership type than by domain per se  
payment processoryes   
     
Contact type & subtypeno   
CampaignnoDesirable  
Contribution typeno(in multi-country models this might be desirable whereas national organisations are likely to think it a bad thing)  
Contribution PagenoDesirable  
Contribution PremiumnoDesirable  
EventnoDesirable  
Custom fieldsno   
Dashboardyes   
Dedupe rulesno   
Financial Accountno   
Groupsort-ofGroup visibility is dictated by the multilevel module if installed.  
Scheduled jobsyesbeware - your mails won't go out if you don't configure for all domains  
Location typeno   
Domain locationyesie. street address etc for your organisation is per domain  
Mailingyesthese are per domain - not quite if there is impact of this other than that it knows to send out the crons from the right site - thereby getting the permissions right  
Mail settingsyespop / smtp / from addresses are per site  
Import & export mappingsnoDesirable  
Menu & navigationyesThis is fairly problematic as, at least on the upgrade to 4.1, only the main site menu was upgraded  
Message templatesno   
Logos & headersno

Desirable

This isn't something currently storable in Civi & to add your logo / header to workflow templates you need to edit all the individual templates but to support multisite we need to look at storing logos & headers so a smarty token can signify them

  
Option groups & option valuespartiallyThe option value has a domain id. It doesn't seem to be heavily used - ie. I found mail approval, grant_types & from_email_address to be the only ones with domain ids. But this seems like it might be a good angle for events & others - eg. if the event_type_id is for that domain or has no domain then show on the page.  
Price setspartiallyThe price sets themselves are but not the price fields & values - which makes the idea of having one price set which shows different fields on each site impossible.  
Profilesno   
Relationship typeno   
Report instancesyes   
Smart groupspartiallyIf multilevel permissioning is installed then permission to view groups in other parts of the hierarchy is restricted by ACLs  
Settingsyesthe CiviCRM settings table is domain specific  
Surveyno   
Tagno   
UsersyesUsers are separately matched to civicrm contacts by domain  

 

 

Étiquette
  • Aucun