No - they're the same 70,000 people. Since the requester company ID goes into field 112 we currently need to put all of the requesters into each company. Otherwise anyone could see any ticket.
From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Friday, February 27, 2009 4:34 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** I'd like to see if I'm understanding something correctly. Are there 70,000 people in each of the companies, because you've added the same 70,000 people to each company, or does each company have a separate set of 70,000 people unrelated to the people in any of the other companies? Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 1:52 PM To: arslist@ARSLIST.ORG 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___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. __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"
