Nestable Groups in CiviCRM

One of the perpetual problems U.S. PIRG runs into with off-the-shelf software is that most of it assumes one of two usage scenarios:

1. A single organization with no need to isolate any sets of data from any others beyond a simple user-by-user permissioning system (if your lucky). This is the most common.
   
2. Multiple organizations with the need to access the software from many different locations, but with complete isolation between the organizations' data in the system and no easy way to combine it. This is less common.
   

Unfortunately neither of these scenarios fits U.S. PIRG (and lots of other organizations). We have a national lobbying office in D.C., many state-level organizations across the country, and a few centralized departments that work with most or all of them. So we really need a hybrid of the two options above. People in the state groups shouldn't have to wade through other groups' data to get to theirs (not to mention that an errant "delete all" command or security breach in one of those offices shouldn't affect other groups' data). But at the same time, the central departments need to be able to routinely work with aggregate data across all the groups.

Here's an example: Let's say we have a group here in Colorado called CoPIRG (we do). They have a list of online activists, a list of media contacts, a list of current staff, a list of alumni, a list of student activists, a list of donors, a list of issue experts, and so on. They want to keep all that under the CoPIRG umbrella without it getting all mixed up with other groups' data (potentially even other groups in Colorado; this would be very confusing).

Now let's say we have a centralized online organizing department (we do, and I work in it). What if we want to send an action alert to everyone on every online activist list across the country? We need to be able to quickly combine the CoPIRG online activist list with the Florida PIRG online activist, the CalPIRG list, the Maryland PIRG list, etc.

Most software makes this kind of flexibility awkward at best, downright impossible all too often.

Which brings me, at long last, to the subject of my post. We are working to support this kind of functionality more readily in CiviCRM by making groups nestable. I'm using the word "groups" here to refer to CiviCRM's feature for combining contacts into logical groupings. Making them "nestable" means you'll be able to put groups inside groups inside groups inside groups...

Here's how this would play out in the example above:

CoPIRG would be a CiviCRM group. So would CalPIRG, Florida PIRG, etc. Each of these groups would have a nested sub-group called "CoPIRG Online Activists," "CalPIRG Online Activists," you get the idea. We would also have a top-level group called "National Online Activists." Each of the "XXPIRG Online Activists" groups would also be sub-groups of this. (We're supporting multi-parent relationships between the groups.)

CoPIRG staff would have read/write permission for their whole group (and thus any sub-groups of it as well). The staff in my department would have read/write permission for the entire National Online Activists group. This keeps our data isolated when it needs to be, but combined when necessary too.

We would then repeat this setup for the local and national media lists, alumni lists, donor lists, etc.

Obviously this is nowhere near the only usage scenario nestable groups will enable CiviCRM to support. The new flexibility, especially when combined with the new permissioning system being planned for the 2.0 release (also when nestable groups will make their debut), will make CiviCRM a much more flexible system overall.

We already have the basic functionality working. The main thing left to do is implement an intuitive widget to create and edit group nesting relationships. We're hoping to get this out the door in the next few days as CiviCRM Standalone v0.4. Stay tuned!