Be warned: As we ramp up Next Generation Project planning and development, we’ll be coming to the community for more and more feedback and advice. This is one of the easiest ways in which you can shape the future of your software—if you have thoughts on a particular topic and the time to respond, join the discussion.
Andrew asked some questions last week on Postal Addresses; I’m here to ask about Control Groups. Control Groups have an interesting history in Tessitura. Implemented originally in v3.2, they were an attempt to solve the problem of how to limit the visibility of certain parts of the data. For example, how can I let a user see some contributions, but not all contributions? What started as a test of the concept (Attributes was the first entity to get Control Groups) has grown in Tessitura to cover almost all aspects of the application and has been quite successful.
We’ve been mulling over how to deal with Control Groups in the new software and have sort of come down on the side of keeping them more or less like they are now--tied to user groups and then tied to certain entities in the database. If we were only doing a service layer on the data, then we might implement the data filtering in the service itself. But we are also planning on having a separate reporting database that is available for reporting, analysis, list building, etc. and this reporting database can be accessed by any number of outside applications and data access methods. For this reason filtering the data in the database itself (as we do now) seems to make sense to us.
But this is not a totally settled decision and here is where we need your feedback. So it’s basically the same questions again on a new topic:
What are some challenges that you have surrounding Control Groups today? Do you know of future business needs that could impact Control Group use in the future?What do you like about Control Groups functionality in existing Tessitura? What would you like to see changed/improved about Control Group functionality?
Chuck,
Story 1:
Joe an IT manager is looking at his list of control groups. He has not been with the organization that long as is trying to figure out how control groups are being used. In Next Generation Tessitura he presses a button when looking at Control Groups and is shown what is going on. I’m not clear exactly what he is shown. But he needs to know what people or groups have access to a particular control group. (He can assign control groups to individuals.) He also needs to know what rights are being added to group by users that get the control group access. And the cool thing about how the new security system works regarding control groups is that there is one place that an administrator can go to see all this information in a consolidated way.
Story 2
Sadie a marketing intern has been asked by her boss to develop a set of marketing lists and extractions containing some sensitive information. Sadie is good at set theory and does a great job doing the extractions and list building. However, she can never remember to make sure that control groups are set on the lists. One day her boss Dave happens to be sitting with Trish a development managers and discovers that Trish is seeing the sensitive data that Sadie has been generating. Dave hits the roof. He does not want to fire Sadie because she is doing a great job with the lists and extractions. Therefore, he goes to the new IT manager Joe and say fix it. Joe says OK I can make Sadie default Control group for List and extractions be the Control group for the marketing sensitive data control group. Joe is a hero. Sadie keeps her job and Dave and Trish can keep their secrets from each other.
Non Stories about control groups.
Control groups have to be assigned to groups. This can cause us to add a new group from many individual users who do not fall into existing rolls. This leave a large number of groups in the system that were needed at one point to meet a particular set of business needs. It would be nice to have the ability to assign control groups to users and to groups in the same way attributes can be assigned an many different levels in active directory.
That’s all for now.
--Tom
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif Sent: Tuesday, January 19, 2010 7:14 PM To: Thomas Brown Subject: [Tessitura Next Generation Forum] Control Groups
What are some challenges that you have surrounding Control Groups today? Do you know of future business needs that could impact Control Group use in the future? What do you like about Control Groups functionality in existing Tessitura? What would you like to see changed/improved about Control Group functionality?
You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!
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
Story 3
Joe the IT manager came to the organization and and had experience with Active Directory an and windows but no experience with Tessitura. He was relieved to discover that administering security for Tessitura was just like administering security for active directory and SQL server. There was a plug-in to the Windows Console that allowed Joe to use his existing security and department groups to control Tessitura Access.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Morgan L'Argent Sent: Wednesday, January 20, 2010 2:55 PM To: Thomas Brown Subject: Re: [Tessitura Next Generation Forum] RE: Control Groups
From: Steve Carlock <bounce-stevecarlock1071@tessituranetwork.com> Sent: 1/20/2010 1:24:59 PM
Or a plug-in to use any existing LDAP server's users and groups.
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.