• Replies 1 reply
  • Subscribers 336 subscribers
  • Views 31 views
  • Users 0 members are here
Related

Confused on Constituency User Security

Randall Mitchell
$organization

Perhaps I have missed it in the documentation which is entirely possible as there is much to read about regarding constituencies. For Tessitura access, I manage the Tessitura Security module for all of our users. When we bring in another organization, I'd like them to manage their own users and security. Is the security module setup in such a way that the Sub can create/edit/inactivate their own users for their own organiztion, or will we as the Master haev to be responsibile to creating their users to access Tessitura?

Parents
  • Former Member
    Former Member $organization
    Hi Randall Sadly, no - the Security Module is monolithic - ie if you have access to the Security Module you can do anything; there's no Security on Security. So fundamentally your central admin team (I suppose that means you) will have to do everything. However... In our consortium,we have created a system admin User Group for each org, which has some extended rights over human users, including additional System Tables. We have implemented for those users, a couple of Reports that let them change the two security objects that were causing the most work for the central admins, and the most stress for users in terms of not being able to change them in a hurry. First off, we use a localised and consortiumised version of the Password Reset report contributed to Shared Reports by the lovely people at the Royal Shakespeare Company. That's worth it's weight in gold. (Actually more than that, i suppose, because it doesn't weigh anything?) And secondly, we have our own simple report that lets users change security on Price Types. Our experience is that once you get rid of those two tasks, the stress level and workload for the central admin folks subsides to a more liveable level. Ken
Reply
  • Former Member
    Former Member $organization
    Hi Randall Sadly, no - the Security Module is monolithic - ie if you have access to the Security Module you can do anything; there's no Security on Security. So fundamentally your central admin team (I suppose that means you) will have to do everything. However... In our consortium,we have created a system admin User Group for each org, which has some extended rights over human users, including additional System Tables. We have implemented for those users, a couple of Reports that let them change the two security objects that were causing the most work for the central admins, and the most stress for users in terms of not being able to change them in a hurry. First off, we use a localised and consortiumised version of the Password Reset report contributed to Shared Reports by the lovely people at the Royal Shakespeare Company. That's worth it's weight in gold. (Actually more than that, i suppose, because it doesn't weigh anything?) And secondly, we have our own simple report that lets users change security on Price Types. Our experience is that once you get rid of those two tasks, the stress level and workload for the central admin folks subsides to a more liveable level. Ken
Children
No Data