Control Groups

Tom's comments on control groups brought back some memories from a prior system I know and love that might fit the needs.  (If you are not into geek/geek history move along, nothing to see here....)

In the days of my youth I worked on an operating system called Multics that had many wonderful features - one of which could apply here:  Access Control Lists.  File system objects (directories and files) had a list of users and their access to that object.  Users were identified (for access control purposes) by a three component string: UserID (optional), ProjectID (optional) and Type (optional).  (If this sounds similar to Unix, it is.  They stole borrowed it from Multics.)

The UserID maps directly to a Tessitura UserID, the ProjectID maps to a Tessitura Group, and the Type could probably be ignored (it was used to identify if the process was interactive, absentee (equivalent of a batch job), or daemon (system process)).  A couple of quick examples:

*.Development      this would work like the existing groups do today.

TBrown.*               this would be Tom on any group

Joe.SysAdmin         this would be Joe in IT, but only when on in the SysAdmin group

*.*                         this would be everyone

I'm not going to suggest that this is the way to go, just something to consider.

Steve, its interesting that you mention Access Control Lists.  I've seen the phrase used in a lot of the Web content managers (CMSes) I've test driven and while I think each particular one implements it a bit differently, they all share the same basic properties which you describe.  A combination of permissions assigned at different levels.  Since the prevailing idea is for a web based application it may be worth taking a look at what large CMS applications are doing in this area.  I am really only familiar with the open source varieties (Drupal, CMSMS, Joomla, even wordpress) but many of those communities have dedicated a lot of resources to the problem.  I think the idea of control groups is very similar to the idea of a CMS with many layers of control (contributor vs editor vs author vs commenter).

I would like to second the notions of adding individuals to control groups as well as being able to add multiple control groups to be assigned to a bit of controlled data.

I'm sure there are better minds than mine working on this :)  Can't wait to see how it progresses.

The problem with straight Unix-style permissions is that you can only grant permissions for one group on any given object. What we really need is ACL (access control lists). ACLs allow you to give any level of access to any number of individuals or groups. And the permissions are additive, so you can stack up permissions for people that work in more than one group without having to make a special access group just for them.

   -Morgan

Or a plug-in to use any existing LDAP server's users and groups.

   -Morgan

I strongly second the notion of LDAP integration and the ability to synchronize LDAP/AD users and groups.   I don't think you could truly consider an application to be 'modern' without integrated authentication and access control capabilities.

One need we have quite frequently is to have more access levels tied to control groups.   Right now, either a User Group has access to a Control Group or they don't.  There is nothing in-between.   It is frequently useful to be able to grant certain user groups the ability to view/read subsets of items (such as campaigns), but not be able to edit or delete all of the subsets.   We'd like to see access levels including Read-Only, Edit, Delete, See in a List but not see details, or any combination of the above.   So when a particular Control Group is assigned to a User Group, we'd also assign the correct combination of Access Levels for that User Group/Control Group.

To try to explain this more clearly:  currently, if a User Group has write access to any data (such as campaigns), they have write access to ALL items of that type of data for ALL control groups they have access to.  As an example, we have a group that needs to be edit certain campaigns.  So they have such access to Campaigns.   Although we can ensure they only have access to campaigns assigned to Control Groups they have access to, they can now make changes to ALL of those campaigns, .  There is no way to allow them to make changes to campaigns with certain control groups, and read-only access to certain other campaigns.

Another key need is more flexibility in dynamically assigning access control.   Currently, an administrator has to create control groups as necessary, and only one control group can be assigned to a given piece of data, requiring a great number of Control Groups to accommodate all the various permutations and combinations, or a great number of Control Groups so you can have a control group for each and every piece of data (for instance, a different control group for every Note Type), and the need to assign many control groups to each User Group.

We'd really like to see some sort of dynamic, logic based setting of access.   Forgive me Chuck, but some sort of logic-based "rules".    It could work much like the criteria builder in List Manager or Extractions, with diffferent criteria joined by "AND" or "OR".  So for instance, we could set up a rule along the lines of:

USER_GROUP = 'DEVELOPMENT-2"

AND DONOR_LEVEL > "I50"

AND YEARS_SUBSCRIBER > 5

then ACCESS = "READ ONLY"

The ability to define rules of this type and assign the rules to various data items would make the system signficantly easier to manage and more foolproof, since as new data items are added they could in many cases automatically fall into the new rules.

I might be missing the point, but don't Control Groups give you this now?  You can create a CG, assign it to some (or all) campaigns and then give different User Groups either just read rights or read AND edit rights to the Control Group.

Yes, my example wasn't the clearest.  Right now, you either give Read-Only, or Read and Edit.   More granularity would be helpful -- such as Delete, View in List but not see Details, etc.

So, I'd like to toss out a few musings on hypothetical control group (or if we rebrand to control set, partition, category, brand, elephant, etc) functionality for the discussion.  What if control group security could be instituted in a hierarchical fashion, like LDAP applied to the windows file system?
There are many hierarchies in Tessitura...Here are just a few (some may debate these structures, but humor me for a moment!):

Season Type --> Season --> Production Season --> Performance
Appeal Category --> Appeal --> Source Group --> Source (maybe throw Media Type in there?)

One of the current concerns we tackle when asked for a new object to utilize control group security is the number of concurrent objects with control group security in a given context.  We try our best to maintain a "predominant" control group in any given situation.  This is partially why you don't see a control group, for instance, on individual Performances, because Season already has a control group structure.  This is also why we don’t necessarily jump at the thought of adding a control group to, say, campaign category, as this very easily puts us in a situation of applying control group security to the same schema/structure twice.  Maintaining a “primary” control group the security context (in most situations) to a simple construct and not require a multi-dimensional take using multiple elements.

So, imagine that you had the option of applying control group security at any level in the hierarchy, with objects lower in the hierarchy inheriting the context of parent item.  For example, as I can now I could create an Appeal titled “2010 Board Solicitation”, control grouped to senior level fundraising staff.  Only executive and senior development department members could see or utilize sources under the appeal.   This implies that every year the “[CURRENT YEAR] Board Solicitation” needs to have control group context for “senior level development”.  What if you could apply the control group on the appeal category “Board Solicitation”, and not have to rely on control group security at the appeal level?  Going the other direction, picture a matching gift/corporate appeal.  This appeal has a single source under the appeal that is being used in conjunction with a marketing push for ticket sales (hypothetical for sure!).  It doesn’t make sense to allow ticketing agents full access to the appeal, as the other sources don’t pertain to ticketing.  It does make sense that you want to allow ticketing agents to utilize the single source for ticketing sales.  What if you could control group the sources under the appeal?

That may not be the best illustration, but here’s another example.  My organization has a few Seasons every year that segregate performances and events along product lines (Childrens’ vs Main Stage vs Education, e.g.).  Student rehearsals fall under the banner of “education”, but for the Finance department’s expenses and settlement purposes, student rehearsals of Main Stage events fall under the Main Stage season, not Education.  Would it be convenient to allow the ability to control group a few performances to a different context, so for instance, education would have the ability to see and work with the rehearsals, but may not be able to see/work with other Main Stage performances?  Of course, you could use Mode of Sale in this instance, but I'm looking at this simply from a "I can see this, but can't see that" mentality.

Another means of deployment here is one of global configuration.  As an administrator, I decide what level control group context is determined.   Does an administrator simply determine that, for instance, control groups can be set at the “Appeal Category” level, but not any lower?  What if this setting is changed?

This of course brings many ramifications and questions:
-    UI design:  how do you show/edit/maintain control groups that can be assigned at any level in a hierarchy?
-    UI design:  How do you make this easy for interpretation?
-    Inheritance and overriding: If a season has a control group, can I override the control group by assigning one to a performance in the season?
-    How does this affect reporting?
-    Does this make configuration and security more flexible?  Easier to manage, or more complicated?

Thoughts?
(no promises here, of course!)
-Ryan