Re: Version 7 Permissions Model
That sounds like it may work for what you need. I wonder if it would be a better approach to disable the workflow that adds the contact and customer companies rather than simply overwriting it with a new value. That way, you're letting the system function the way it normally should, except that you're effectively saying we don't need/want the customer or contact company to be able to view this record. That way, if there is other multitenancy functionality that you may not currently be aware of but may eventually need, you haven't broken that - you've simply limited the scope of what it provides by pulling out what you know you don't want. Does that make sense? Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Monday, March 02, 2009 5:09 AM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** This was the model I was going to use in my original email. The problem here is that if they all have access to the customer's company then they can all see everyone else's tickets. I built a filter to remove the requester and contact companies from field 112 upon save which appears to be working. I'm wondering if this is the best way to do things. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Friday, February 27, 2009 5:27 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** Michael, What if you broke the people into six groups instead of five? Your IT staff would be split into Schools A-E and would only have access to the Schools whose tickets they need access to. Your customers would then be split into another company, say Customers. All of your support staff would have access to their own company and the Customers company. That way, they could search the complete customer database, but they would still only have access to the Incidents generated in their company. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2: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 mailto: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
Re: Version 7 Permissions Model
This was the model I was going to use in my original email. The problem here is that if they all have access to the customer's company then they can all see everyone else's tickets. I built a filter to remove the requester and contact companies from field 112 upon save which appears to be working. I'm wondering if this is the best way to do things. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Friday, February 27, 2009 5:27 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** Michael, What if you broke the people into six groups instead of five? Your IT staff would be split into Schools A-E and would only have access to the Schools whose tickets they need access to. Your customers would then be split into another company, say Customers. All of your support staff would have access to their own company and the Customers company. That way, they could search the complete customer database, but they would still only have access to the Incidents generated in their company. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2: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 mailto: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
Re: Version 7 Permissions Model
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:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2: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 overwrit
Re: Version 7 Permissions Model
Michael, What if you broke the people into six groups instead of five? Your IT staff would be split into Schools A-E and would only have access to the Schools whose tickets they need access to. Your customers would then be split into another company, say Customers. All of your support staff would have access to their own company and the Customers company. That way, they could search the complete customer database, but they would still only have access to the Incidents generated in their company. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2: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 mailto: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 I
Re: Version 7 Permissions Model
Michael, We have a similar situation with the North Dakota University System, there are 11 campuses that use the same Remedy system. We share the same people database (CTM:People). We went with Single Tendency, so incident could be easily transferred between campuses. The larger campuses provided enterprise IT services to the smaller campuses. There is one Company and Support Company, North Dakota University System. Each campus has their own Support Organizations and Support Groups. Support staff are placed in one or more Support Groups. To restrict access to an incident, we used row level access on the incident, restricting access to the Support Group. Member of a Support Group can access an incident if one of their Support Groups created the incident or if the incident was ever assigned one of their Support Groups. If I were to do this again, I would put the restriction on the Support Organization level. John Michael S. Davis 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___ -- ** John A. Underwood NDUS Help Center Project Manager IACC Rm. 206NDSU/ITS Help Desk Manager & NDUS Help Desk Co-Manager 1320 Albrecht Blvd. Office: (701) 231-6109 Fargo, ND 58105Cell: (701) 730-5337 e-mail: john.underw...@ndsu.edu Fax:(701) 231-8541 ___ UNSUBSCRI
Re: Version 7 Permissions Model
Well, as I understand it, that's the problem. Adding each company to a customer's Access Restrictions doesn't make that customer any more visible to the other companies - it just increases what that customer has the potential to see in the system. Creating a separate People record in each company for a customer is not an option either as that multiplies an already large number of customer by 5 making the system too slow. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Chowdhury, Tauf Sent: Friday, February 27, 2009 3:06 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** Yes, so in that case, what about just adding the end users to each company. If they are end user's, they most likely won't have permissions to search incidents anyway since they are non-support. 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 Lyle Taylor Sent: Friday, February 27, 2009 4:59 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** Granting the customer Unrestricted Access would allow them to see tickets from any company, but would not allow the support person from a different company to see the customer's people record if the support person doesn't also have Unrestricted Access. Lyle 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. __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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
Re: Version 7 Permissions Model
Yes, so in that case, what about just adding the end users to each company. If they are end user's, they most likely won't have permissions to search incidents anyway since they are non-support. 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 Lyle Taylor Sent: Friday, February 27, 2009 4:59 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** Granting the customer Unrestricted Access would allow them to see tickets from any company, but would not allow the support person from a different company to see the customer's people record if the support person doesn't also have Unrestricted Access. Lyle ** 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"
Re: Version 7 Permissions Model
Granting the customer Unrestricted Access would allow them to see tickets from any company, but would not allow the support person from a different company to see the customer's people record if the support person doesn't also have Unrestricted Access. Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Chowdhury, Tauf Sent: Friday, February 27, 2009 2:50 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** 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 mailto: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
Re: Version 7 Permissions Model
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 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
Re: Version 7 Permissions Model
So, is it something like this: Someone from School A calls the help desk for School B, and in order to log the ticket, the support person at School B needs to be able to look up the person from School A so they can make them the contact for the ticket? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Michael S. Davis Sent: Friday, February 27, 2009 2: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 mailto: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
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 mailto: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
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 mailto: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 w
Re: Version 7 Permissions Model
OK. Take a good luck at Chuck's reply. He has it right. There is no need for you to have everyone in each company or to fiddle with the permissions in this way. Multitenancy does this for you if you get the people records set up correctly. Just add the people once to the most appropriate company for them and add that company to their Access Restrictions. For people that need access to more than one company, just add the other companies to their access restrictions as well - that will add the permission group(s) for the other companies to their User record allowing them to see records from those 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 2:38 PM To: arslist@ARSLIST.ORG Subject: Re: Version 7 Permissions Model ** 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.
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 mailto: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
Re: Version 7 Permissions Model
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"
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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
