Based on http://wiki.civicrm.org/confluence/display/CRM/ACL%27s%2C+Organic+Groups+and+Multi-Org, the following qualify as deliverables for meeting the project's goals. There is a list of caveats at the end that need to be accounted for in these deliverables:
1. Complete OG_civicrm module in its current form, including bug fixes, for use with CiviCRM 1.8.uas & Drupal 5.2
Extensions to the above model
To make the above module applicable to the current scenario, we will need to upgrade og_civicrm to use Drupal 5.2 and CiviCRM v1.8. We will also need to extend the module to create CiviCRM ACL for each admin. Here are the steps for various operations
Creation of an OG 'xyz'
- Create a CiviCRM group with the name 'xyz'.
- Create another CiviCRM Group 'xyz: Administrator'
- Create an ACL Role 'xyz: Administrator'
- Create an ACL GroupJoin record to link the CiviCRM Group 'xyz: Administrator' and the ACL Role 'xyz: Administrator'
- Finally create an ACL giving ACL role 'xyz: Administrator' permission to perform the 'Edit' operation on a Group of Contacts
Implementation
Use corresponding hook_nodeapi() operations
http://api.drupal.org/api/function/hook_nodeapi/5
- Listen to $op == 'insert' in hook_nodeapi()
- You can identify a node as a og group by using og_is_group_type($type)
- Implement a hook by defining mymodulename_nodeapi(...) in your mymodulename.module.
- On the URL above you can find more info about the arguments that are being passed into nodeapi.
Deletion of an OG 'xyz'
Note that the DA implementation of this will suppress this feature, Ian/Alex: can u confirm.
- Delete the ACL that gives ACL role 'xyz: Administrator' permission to perform the 'Edit' operation on a Group of Contacts
- Delete the ACL GroupJoin record to link the CiviCRM Group 'xyz: Administrator' and the ACL Role 'xyz: Administrator'
- Delete ACL Role 'xyz: Administrator'
- Delete CiviCRM Group 'xyz: Administrator'
- Delete CiviCRM group 'xyz'
Implementation
see previous
- Listen to $op == 'delete' in hook_nodeapi()
Add/Remove a user 'abc' to OG 'xyz'
- Let 'cid' represent the equivalent contact id for user 'abc'. If no contact present, create one
- Add/Remove 'cid' to/from CiviCRM group 'xyz'
- If 'cid' is/is not an OG admin, also add/remove 'cid' to/from CiviCRM group 'xyz: Administrator'
Implementation
Use the hook_og($op, $gid, $uid, $args) 'user update', 'user insert' and 'user delete' $op for hooking into og. Pull required information from $args. It might also help to look at how hook_og() is being invoked - see the calls module_invoke_all('og', ...) in og_save_subscription() and og_delete_subscription().
(Alex: I haven't actually used this hook myself, I suggest adding it to your module and doing a var dump of $args to the screen for figuring out on what arguments to fire)
3. CiviMail does not have any permissioning / partitioning with regard to mailings. We will have to introduce some sort of permissioning/partitioning scheme to make this useful. Ideally a "mailing" follows the same rules as groups. A person can see a mailing if they have rights to see ALL the groups who are part of the mailing.
4. CiviMail also needs a rich text editor for which a patch has been submitted and we are integrating it into the 1.8.uas branch
5. We expect to do all additional CiviMail work and add enhanced support for UAS batching and other issues in the svn branch: [http://svn.civicrm.org/branches/v1.8.uas/]
6. Develop solution for emailing regional groups (discussed further below)
7. Implement and bug test changes on existing site running CiviCRM 1.8.uas, Drupal 5.2
Caveats: the following hinge on this quote from the original page referenced above: ""This module (OG_civicrm) thus keeps an OG in sync with a static CiviCRM group, i.e. a member of an OG is a contact subscribed to the synced CiviCRM group."
One way sync needed
First, this perfect sync from OG_civicrm is actually not a good thing in this case: Since OG is the mechanism for creating a digital record of membership in the organization, an OG/CCRM bridge for them needs to essentially be one way (OG-->CCRM). *The OG module allows authenticated users in Drupal to unsubscribe from a group, and if this is ever the case for a user, there will need to be a notification message sent to DA admins so that they can confirm the user no longer wants to receive any communications and effectively leave the org (and not that they're just tired of the online group).*
Also, they plan to use OG/CCRM to keep a record of all of their members - even those without email addresses. *The original plan had been to keep track of users using Drupal uids because this information was going to helpful in the donation process, but today (8/29), we changed it so that CiviCRM cids are being used for this purpose. This means that CiviCRM records could now be used as the common identifier for all members and that Drupal uids wouldn't have to be created. That said, the issue arises that these "analog" members are nonetheless members of country groups that are being organized/created by organic groups. The organization will want to search these groups at time to see data on all members -- analog and digital. What do you think is the best solution here, Lobo?*
[This will mean creating Drupal accounts and members of the OGs that will never be used, but who for the sake of record keeping and financial accountability they would like to have in the system. Drupal UIDs will be used in some cases to help validate donations on the reporting/auditing side - the UID will serve as an additional unique identifier when an authenticated user makes an online donation. In other cases, administrators may choose to find a user's UID and associate it with a check payment for the sake of having an additional unique identifier for reporting purposes. While much of this work is done outside the Drupal/CCRM system and shouldn't be a concern here, it needs to be known.}
Various OGs with different rights
There are actually three unique CCK content types that are functioning as OGs: country groups, chapter groups (i.e. Paris, France), and issue groups. Country groups are the basis for organizing their formal membership. Chapter groups serve to provide an additional organizational level that is useful more for organizing on the ground for them - these have less bearing on formal organizational dynamics than country groups, but they still have carefully moderated and accurate membership. Country leaders should all have access to their child chapter groups, but chapter groups will have Drupal administrators without access to the wider country lists.
*Issue groups are a different animal. They will be formed ad hoc and their leaders should not have access to the CRM system or to mailing (unless they are also admins for a country group). Recognizing that this is contradictory to how the module is being built, here are some things that the system should account for:
1. An issue group leader could be any authenticated group member. If this leader is thereby given "admin" privileges in CiviCRM, the person would then naturally have access to all their group members' private information that is stored in the system. This cannot be allowed.
2. An issue group leader would also have access to use the CiviMail system to mail their group members. The communication would appear to come as an official DA communication, but this cannot be allowed either.
What are the options here, Lobo? I know this is one we'll have to figure out together. *
Custom script requirements?
*With the regions: there may be an option to do this in OG so that there doesn't have to be a hack on the CiviCRM side, but we'll need to figure this out next week after a Friday deadline that we are working on. This is in our court for now, but it's looking good that there could be a solution here. Assuming that there is, what does that change for you, Lobo? *
[Old text: Additionally, a fourth level of organization exists - the concept of regional groups. There are three regions worldwide. Since these groups do not have significant meaning to the average member except when the time comes for them to receive relevant region-wide emails, these are not organic groups. The plan has been to create custom queries in CiviCRM/CiviMail so that regional admins with sufficient privileges for CiviCRM use could quickly combine the lists of all the countries in their region for email blasting. This may not be the best solution here and it should be discussed further. It will have bearing on the ACL work.]
