Correct me if I'm wrong but the following would probably work for you: 1. Take all of your non-support end users and mark them unrestricted access and/or create an escalation to populate CTM:peoplepermission groups with company memberships for all the companies you have.
2. Your support users will be restricted to their respective Company. 3. Theoretically, the support user should be able to open a ticket under the end uer's name and only see their respective company tickets on any searches or lookup tables. Tauf Chowdhury Analyst, Service Management Office: 631.858.7765 Mobile:646.483.2779 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 4:46 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** I mean that we have 70,000 people in the database and each one of them must be available to every company. The callers could call one of five helpdesks, depending on what their problem is. I think this is where I'm a little dense. If the people are all in one company then every user has to have permissions to that company in order to log a ticket under the person's name. If they have access to that people company then they can see any ticket logged for that user, regardless of which operating company actually logged the ticket. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Friday, February 27, 2009 4:42 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** What do you mean that each person must be available for each company? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2:41 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** I understand all of this, but each person must be available for each company. There are only two ways to do this; either have one people database where each company pulls from or load the entire people database into each company. If we use one people database then everyone needs access to that company and thus can see any ticket created from a user in that company. Unless I'm missing something. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Charles Baldi Sent: Friday, February 27, 2009 4:36 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** Michael, You should not need to go through those hoops. It sounds like the Multitenancy configuration in ITSM 7 will work for you. You create multiple companies as you say, but no need for multiple People forms. Each person record belongs to a single company (whichever), then you grant explicit access for that user to whatever company's objects they should see. This is on the Access Restrictions table on the Login/Access Details tab of the People form. You de-select Unrestricted Access and grant company-specific access. This way, users who you have given access to School A will only see School A's Incidents, etc. You then have the option of loading company-specific operational categories, etc. Read the whitepaper on Multi-Tenancy too. Regards, Chuck Baldi On Fri, Feb 27, 2009 at 3:51 PM, Michael S. Davis <mida...@exchange.upenn.edu> wrote: ** 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___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __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___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ ********************************************************************** This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
