When we originally designed and wrote Tessitura, there were some pieces of functionality that made their way into the system that I never really thought were fully formed or thought out. As a result these features tend to get very little use or confuse many users.
One such feature is constituency-based security. This feature allows you to define rights to one or more constituent functions (i.e. editing addresses) based on the highest ranking constituency of that constituent.
Development stories concerning constituencies are starting to come into view and we need to explore whether this security paradigm is worth continuing.
In my opinion, the whole idea of constituency-based security loses a bit of its shine as soon as you realize that it's all based on the highest ranking constituency only. In addition, the concept was put in place well before Control Groups was ever thought of and we might have thought twice about it if Control Groups were in the original plan. It's not that Control Group functionality replaces constituency-based security, but rather that sometimes you have to step back and wonder whether there aren't too many layers of complexity. Especially if one of those layers is not often used--a survey of Network implementation consultants seemed to show that very few sites ever implement this functionality, at least initially.
Another factor prompting this thread is that several times our internal discussion on on how we might better use constituencies going forward has been hampered when someone says "yeah, but don't forget about constituencies and security".
We've tried to model out what would happen if we changed the model so that security could be based on "any" constituency instead of "highest ranking" constituency. But that always creates problems. What if a constituent has both constituency 1 and constituency 2. Constituency 1 says they're allowed to edit addresses and constituency 2 says that they are not. What to do then?
So some help here, please. How many sites use this functionality now and how passionate about it are you?
As always, thanks in advance for the feedback!
In general, I do see organizations dabbling in security based on constituencies. However, I have really never seen an organization implement it successfully based on the current structure.
To my knowledge, one of the most important requirements (and reasons for use) is that the licensees want to implement limitations on who can edit very important constituents and their account information. The limitations are for those elite few that are “locked down”. The majority of accounts are open to whomever for editing.
My two cents.
Cindy
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif Sent: Thursday, February 18, 2010 2:42 PM To: Cindy Emig Subject: [Tessitura Next Generation Forum] Constituency Based Security
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!
Thanks for all the feedback.
For those of you that use constituency-based security now, could the business value be achieved if you were able to put restrictions on the constituent as a whole? So instead of saying "this user group can't edit ADDRESSES where the highest ranking constituency is x" you would say "this user group can't edit ANYTHING on a constituent if they have this restriction code"
Obviously this needs to be fleshed out a bit more but in general is something like this worth thinking about some more?
Hi Chuck
We don't use constituency-based security at all. [In fact i still remember a long session in front of a whiteboard in our implementation project office when you talked through all of the Tess security options and convinced us that it wouldn't be useful and we could safely ignore it]
If it was made more flexible as Alan suggests, or even just specific-constituency-based (being able to put a control group on a constituency, for example, which would lock you off from editing anyone with that constituency if you didn't have that control group), I could see it enabling various stories about how we don't want specific constituents being edited at random.
On the other hand, I could also see it enabling turf wars between departments and organisations about "owning" particular constituents, which we're just getting away from, and severely disabling our progress towards the nirvana of one individual-one constituent - If Gina the ticket seller has to sell a ticket to Julie Hotshot-Lawyer and she can't access her constituent record, what's she going to do? Well, obviously, she'll create a new record so she can complete the sale - Hullo... duplicate problem even worse.
And on the third hand, it might be useful to enable locking of specific bits of a constituent record - we have a long-standing enhancement request in to be able to lock off the gen sal for specific constituents - ones with strong preferences for very non-standard salutations, basically, who require eternal vigilance to stop people taking the liberty of switching them back to the standard version.
But that's a much more fine-grained version of constituent security, and going very far down that track probably leads to getting lost forever in the Forest Of Administrative Complexity? Si?
Actually that would not work for our use of this item today, we want the call center/box office or education department to be able to edit to the address or personal information, but not be able to sell a contribution (membership) to the child record. So we need to be able to do one thing but not the other, which in this case this security option works great!
Jeanette Boudjouk
Database Analyst
Science Museum of Minnesota
651-265-9846
jboudjouk@smm.org
Omnifest 2010 brings five giant screen films to the Omnitheater for six short weeks from January 29 through March 11. Members see it free! View this year's films and trailers at www.smm.org/omnifest. The Dead Sea Scrolls: Words That Changed the World exhibition opens March 12. Witness authentic 2,000-year-old manuscripts, including the earliest biblical writings. Spiritually significant. Scientifically stunning. Visit www.smm.org/scrolls.
From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Chuck Reif Sent: Monday, February 22, 2010 2:47 PM To: jboudjouk@smm.org Subject: Re: [Tessitura Next Generation Forum] RE: Constituency Based Security
From: Cindy Emig <bounce-cindyemig9904@tessituranetwork.com> Sent: 2/22/2010 7:43:01 AM
Spam Not spam Forget previous vote