Constituency Based Security

Chuck – We do use it here in Pittsburgh on the consortium level and have found it very useful.

When we first looked at using it, we found it frustrating that it was based by the highest ranking constituency.  We had to do a bit of finagling for the consortium wide constituency to be sure it would have the highest rank.  So far it’s worked very well, but we’ve kept it relatively simple.  Without ranking, I would think some other rule would need to be in place, but wonder if that would make it more complicated.

_________________________________

Rebecca Harriman

Tessitura Operations Pittsburgh Consortium

412.325.2230

harriman@pgharts.org

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!

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!

Chuck – We do use it here in Pittsburgh on the consortium level and have found it very useful.

When we first looked at using it, we found it frustrating that it was based by the highest ranking constituency.  We had to do a bit of finagling for the consortium wide constituency to be sure it would have the highest rank.  So far it’s worked very well, but we’ve kept it relatively simple.  Without ranking, I would think some other rule would need to be in place, but wonder if that would make it more complicated.

_________________________________

Rebecca Harriman

Tessitura Operations Pittsburgh Consortium

412.325.2230

harriman@pgharts.org

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!

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!

Andrew - We use it to restrict order processing in organization records.  On the consortium level, it was decided that orders would only go into Organizational Contact records and not the organization records themselves.  So to prevent orders from going into those types of records, we created a consortium wide constituency and for that constituency removed A/D/E/V rights to Ticketing Orders Module for all the organization ticketing groups.

_________________________________

Rebecca Harriman

Tessitura Operations Pittsburgh Consortium

412.325.2230

harriman@pgharts.org

Hi Rebecca,

Can you elaborate on how you use it, what specific business need are you satisfying by using Constituency based Security?

Thanks!

Andrew