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

Musing as a result of various tests

GROUPS

Groups can be set to have an L2 as the parent thereby restricting the group membes to the L2 admins - good.

A group can have more than one L2 parents which makes the group members available across all L2 admin - this may be an option for setting up trans-state groups of reps etc though it does mean one L2 admin can edit delete contacts belonging to another L2.

When a group has more than one L2 parent i get access denied when at participating L2 group and trying to access members of the group  - BUG

L1 can delete an L2 group - can and should this be preventable?
L2 person can delete one of the L2Parent Groups - any way to 'lock' such a Group so it can't be deleted so easily?
At L2 in Adv Search i only see L2 Groups - Good
CIVIMAIL
This can be set up so CiviMailings sent at L1 can go out with the relevent L2 branding, logo etc - untested
L2 can only see their own Groups at point of selecting Groups for mailing to. - good

CIVIMEMBER/CIVICONTRIBUTE

If memberships are tied to L2 orgs then it would be good if when adding a Membership at L2 we only saw Membership Types related to that Parent Org

CiviMember dashboard should only show Memberships related to that ParentOrg
TAGS

Tags are not in anyway affected by the multisite system.

Therefore tags can be used site wide - meaning L2a will only find people tagged in their level

Tags can have parents, therefore it is possible to have a set of state-specific tags using a state parent-tag

Could these be made 'hidden' to help declutter for other states? (ie can we run a hook to specify that some Tag belong to some L2 orgs?)
ADDING CONTACTS

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. At present if you create a new Group at time of import - access denied for L2 = BUG

http://issues.civicrm.org/jira/browse/CRM-5417
CIVIREPORT

Currently does not have ACL applied to it. JIRA issue in queue http://issues.civicrm.org/jira/browse/CRM-5104

can set Reports to Parent Group in Report Criteria - via set filters but doing so resulted in wrong search results

eg run Report at L2 for that ParentGroup but got meaningless result of one other ParentOrg
ACL HOOK

Chris has demoed that we an use ACL Hook to give L2s their own Custom Data tab which is hidden from others - good

Will we be able to also use ACL Hooks to do more granular ACL within the L2 level ie to provide subregions access to their own contacts - or does this happen via a 3rd level of multi-org ie an L3

if so does L3 require its own domain (not desired by us) or can they just piggyback on L2 Domain

Or can we both have L3 and use ACL Hook

MULTISITE AND OG

Any obvious conflicts going to happen here if we are trying to use OG synch in either direction?

IF the L1 site has OGs that members from all L2 belong to, are they going to be logging in via L1 to access these and does that mean that L2 admins will have access to L1 records?
CIVIEVENTS

How can events be tagged to indicate they belong to an L2 organisation and therefore all results relating to the event only show on relevant L2 screens
ACTIVITIES

Again would be logical if we could associate Activity Types to a Parent Org so L2 can just see 'their' Activity types
VIEWS
how might the multisite set up impact on delivering information to listings via Views for the L1 site or the L2 sites?

Étiquette