Data Structures in Related Communities

[FatherShawn]

On my horizon is an implementation in which parishes have their own Drupal instance and there is at least some data sharing of basic contacts between parish and diocese for Civi.  A single ACL partition of Civi has it's own challenges since each parish needs it's own website.  A lot has been written and imagined on this topic:

• Multi-org implementation - notes & concepts
• Multi-level Organization ACL Permissions
• ACL's, Organic Groups and Multi-Org
• Multi-Organization Support in CiviCRM
• Multi Site Installation
• Multi-Org Installation Example
• Multi-Org Use Cases
• CiviCRM for Drupal - Configure Multi-site Installations

If any interested parties would like to join in a conversation here to synthesize all this into a way forward I would really appreciate the collaboration!

[SarahG (FountainTribe)]

Have you considered the pros/cons of giving each parish its own install of CiviCRM + Drupal?   Then creating automation for updates/patches (such as using Drush/Aegir/etc) so they all stay at the same version?    Then you could use custom CRON jobs to share the data that needed to be shared.     

Wondering if enough data is different between each parish that sharing a single CiviCRM install would be a headache.  Also, in the case where all parishes share a single CiviCRM database, who would be the chief administer of the system for deciding global settings: such as custom fields, contribution types, event types, profiles, etc.

[FatherShawn]

That's my basic instinct, but I haven't yet had time to read/think through all that's in the wiki.  It's really the contact info that I would want to sync up to the diocesan level.  So that when an address or similar info was changed in a parish the change was also made at the diocese.  I just need to think through the best way to do that and to keep those records associated.

[petednz]

We would most likely be going down the multiorg approach since we have it running for several clients with various complex geographic and other layering.
You can then use a single Drupal site with lots of subdomains - eg Domain Access if sharing content/editing is useful.
Each domain then has civicrm forms - and if someone fills it in at x.yoursite.com then they get added to the container of contacts that the admins of x site should have access to - and ditto admins at site y get access to people who are added front or back end via the y site

hope that helps

if my brevity causes more head scratching than clarity - as it often does - happy to skype you through an example use case if that would help

[Donald Lobo]

Might want to check:

http://wiki.civicrm.org/confluence/display/CRM/CiviDataSync+Specification

basically aggregating n child sites into 1 master site for analytics. This is still a work in progress

lobo

[Eileen]

Father Shawn - the concept of Chapter organisations came up @ the sprint & is slowly coalescing into a more public discussion. Both IMBA & Emphanos are in the stages of working through the documentation you have listed & improving it / coming up with their own.

[FatherShawn]

Hey!  That's cool!   

This is steadily floating up to the top of my pile!  My first task will be to build the diocesan property, which needs contacts shared between 4 or so entities. At the moment that looks like it can be one install.  Once that's operating well I'll bend my mind to an Aegir powered parish platform.