| 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 specific |
CiviCRM Core |
Based on domain_id in payment processor table |
Domain_id set in civicrm.settings.php |
|
| Domain contact details are domain specific |
CiviCRM Core |
Based 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 |
|
| 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 1. 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. |
| 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. multisite_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. multisite_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. |
|
| 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 |
|