Michael, I'm rather tied up getting a live demo built for Asset Management and Analytics for next Tuesday (we are trying to get a conversion to the ITSM Suite pushed through) so I can't read your situation in detail, but you might get some ideas from our multi-tenancy documentation.
http://arsweb4.ars.unt.edu/index_prod.htm - there are five links under the heading "UNT-Specific Documentation for Multi-Tenancy in the UNT BMC Remedy ITSM 7.x system" In a nutshell, all 185,000 of our defined customers are in a "UNT Customer" customer company that ALL of the support staff have access to, so _any_ support staff in any of the 25 companies or 80 support groups (most colleges and departments have independent IT shops, so they have separate companies in ITSM) can create tickets for _any_ of those customers. Moving tickets between support groups in different companies is facilitated by giving every support staff member access to another operational company (UNT Ticket Transfer) which contains public-facing support groups for each support company. Moving tickets between companies where the requester is an internal support staff member is where it gets sticky, and where we had to customize the use of field 112. It looks like I am going to have to do the same thing in Asset if we get it, to make requisitions and contracts visible across company boundaries within the central computing center, so we have already created yet another global company (operational this time) to assign all of our CIs in the CMDB to, as well as all contracts, requisitions, etc. This is necessary since the central computing support staff are homed in separate operational companies by directorate, not one overall company. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2:52 PM To: [email protected] Subject: Version 7 Permissions Model ** I tried posting this twice to the bulletin board but it didn't show up. Anyway, here goes......ok, and now it doesn't like my email address. Trying for a FOURTH time. We are upgrading to version 7 right now and are having some permissions troubles. What we need is for several different schools to run Remedy helpdesks, but those schools must be segregated from each other. In other words, our School of Nursing has a helpdesk and they cannot see tickets from the Research Services helpdesk. This is easy enough in that we can create separate companies. The original plan was to create five different companies. We have run into two problems, though. Each of these companies would need to have their own people table. Since the people from across all companies are held in one table this makes searching take longer than necessary; each company will have 70,000 people so when it searches it actually searches through 350,000 records. The second problem is that one of the groups in IT will need to have access permissions to two other companies. This means that when they look up a name they will get three returns - one for each company they have access to. Our consultants recommended that we do not modify the existing permissions model as it is a nightmare to do so and will be a nightmare come upgrade time. I did some investigating and experimenting and agree with them. It is very complicated. So I came up with another solution. Instead of breaking the permissions model I created a filter that will set field 112 to the Support Company ID, overwriting anything that is in there such as the requester ID and contact ID. This filter will run last upon create and modify. I created one customer company and three operating companies. From the customer company I created three users and some non-user people. Each of the users has access restrictions to the customer company and one of the operating companies. Without this filter on the tickets that they log can be viewed by anyone. This is, of course, due to the fact that the requester company ID is in field 112. After turning on the filter and modifying each ticket the users could see only the tickets where the support company was in their access restrictions - thus ignoring the customer company. As a follow-up, I created another user with access to two of the operating companies. This user could see tickets logged for those two companies but not the third. This appears to have worked, so I simply added the change form to the filter. Again - same results. In effect, what I have done here is that I have one company that holds all of the people, including all of the users, and have created three operating companies with no users but with support groups. I have not modified any existing workflow in any way, other than to make it irrelevant by overwriting field 112. A consultant friend of mine mentioned a number of minor issues but nothing that cannot be overcome. Our requesters cannot see their tickets now, and I believe a simple join form with $USER$ = 'username' logic will allow them to see them in the future if we decide to go that way. So can anyone see any major reason why this logic will not work? Thanks for taking the time to read this extremely long essay. __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
