When setting up a user account in Tessitura you can apply a Control Group. I've never given much thought to the setting, as I assumed Control Groups were pretty much only relevant where attached to Security Groups. However, it turns out this is not the case, in some situations (and I don't know all of them) it appears that processes/reports will look at the _creator_ of an object, then assess that creator user account's Control Group, then decide if you can see the object based on whether you also have this Control Group.
This is a problem for me because I'd generally just applied the Control Group to users based loosely on department. But this is not becoming a serious hindrance to some important inter-department sharing: namely it seems to crop up with the Customer Service Issue Tracking report.
Does anyone have an idea of where all this particular restriction comes up? My first thought is to just set every user's Control Group to "Default" to prevent this from happening (I don't think any of our Control Group structure was built with this kind of restriction in mind). Can anyone think of a reason why I wouldn't?
Thanks,
Gawain
Hi Gawain,
We ran into this same issue with the Customer Service Issue Tracking report. From what I've seen, it is the vs_metuser view that references T_METUSER.control_group, and that view is only used in these stored procedures:
AP_GET_SOLICITORSAP_GIFTS_BY_SOL_RPTRP_CUST_SERVICE_ISSUE_TRACKING (which is the stored procedure behind the report you mentioned)TP_ORDER_IMPORT_MAIN
Before v12, it was also used as a way to control group solicitors; however, that is no longer the case in v12+ due to Plans. There may be other uses I haven't run into or tracked down.
In our case, after v12, we set all of our users to use the default control group. We did this over 2 years ago and have not seen any problems with it.
I hope that helps!
David
Thanks David, that was exactly the kind of information I was looking for! I assume the solicitors stuff (first too) is pretty much deprecated and the usage in the issue tracking report is something of a fluke, but unfortunately an important report for us right now. I suspect I'll go ahead with taking the control group out of the user accounts then.
To expand on this a little, there is also a trigger and a second view (VS_METUSERGROUP) that reference VS_METUSER, but the trigger is on VS_METUSER itself, and,. and as far as I can see, nothing uses VS_METUSERGROUP.