Re: Support Company based muti-tenancy
So why can't we just create the necessary active links to impose those restrictions each time someone searches or tries to view / modify a change or incident? These can just be custom objects and when you put the form in search mode you could automatically restrict the search . Other than the complexity to derive the access restrictions I don't see any other downside to it. Am I incorrect ? Sent from my iPhone On Oct 3, 2013, at 11:32 PM, Ray Gellenbeck raygellenb...@yahoo.com wrote: ** Agreed. We'd prefer the ability to say... This group's tickets are invisible to everyone else, including sister support teams within our company and other companies. This data in CMDB can be seen by all in our company, but not others. This data in CMDB can be seen by all companies These support KB articles are only for NOC people. These SRM catalog entries are for all companies except (x) and (y). etc In Sony's case, we'd like to offer the app to other sister divisions while keeping some elements proprietary to ours, but take it a step deeper and say the SOC's tickets cannot be viewed by anyone not in the SOC group(s). I have played with 8.1 in a dev sandbox but not delved into multi-tenancy changes yet. In 7.6.04, the model was insufficient in complexity/options to allow this efficiently. Ray Gellenbeck Mgr, BSM Sony Network Entertainment Int'l San Diego, CA From: John Marshall marsh...@gmail.com To: arslist@ARSLIST.ORG Sent: Thursday, October 3, 2013 8:46 AM Subject: Re: Support Company based muti-tenancy ** Hi Ryan, I think that this phrase sums up perfectly what multi-tenancy is “Tenancy is based and controlled at the Company level”. However, I think for my issue I would like multi-tenancy to be defined as “Tenancy is based and controlled at the _Organizational_ level while allowing access to company level data” Here is what I _think_ the issues would still be trying to setup the system with support users having unrestricted access and the end users having access to specific companies. 1. If I give the support users Unrestricted Access then all the support users will see ALL the tickets in the other organization’s area and we only want them to see items in their area 2. End users belong to an overarching company of which all the other (support) organizations are children of that company, so end users will belong to that overarching company vs. a specific “sub company” (organization) Let me see if I can give a use case based on what I really want to do... I work at GWU and ALL the users (end users and support users) will need to belong to the company GWU. I also have 2 organizations, IT and AT, that want to be able to be completely autonomous from one another but still use the same user base (GWU users). I would like to setup the support user in the IT group to belong to a IT “company/org” and the AT support users belong to a AT “company/org” So when a user calls IT to report an issue, I would like the IT people to be able to a) Retrieve the user records from the GWU pool of users (which we can with Support Company Access Config) b) Have the business rules for IT be used to process the ticket. c) Not have the AT group be able to see the tickets that belong to IT Then I would like the same to happen for the AT group when a user calls AT to report an issue. I think the highest priority is based on Incident and Problem, but this would need to cascade to the other ITSM modules as well Again, thanks for the input. Hopefully the above clears up a little bit what I am looking for, however I think that might not be something that can be done with just configuration options (but I am hoping to be proven wrong) John On Thu, Oct 3, 2013 at 9:53 AM, Downing, Ryan ryan_down...@bmc.com wrote: ** Hi John, If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: 1. Support people have Unrestricted Access 2. End users have Restricted Access to the Company (department) to which they belong In ITSM 8.1 multi-tenancy works as follows: Ø Multi-tenancy is a feature in the BMC Remedy Applications that enables you to control which records and specific configuration data are exposed to a user, based on the user’s permissions. Tenancy is based and controlled at the Company level. Various forms in the BMC Remedy Applications expose one or more Company fields that control the tenancy access for a given record. Ø Row-level security typically works as follows: o On main user facing transactional forms: § Tenancy is based on the Customer Company and/or Process Company defined on the record (sets field 112) § Tenancy is also based on the Support Companies assigned to a record (sets field 60900) o Child forms: § Child form should inherit their parents tenancy permissions o Join forms
Re: Support Company based muti-tenancy
One down side to it is that active links are only client side. If these people shouldn't have access to the data, then it needs to not even be filters...it needs to be permissions. Active Links would stop someone from getting the form openbut what about searches in consoles that show the data? What about the ODBC/JDBC reporting capabilitiesthose don't fire workflow...they just use permissions to access data. Active Links would provide one layer of 'stop'...but it would only be one, and it would be overall ineffective in the entire system. On Wed, Oct 9, 2013 at 4:43 PM, Deepak Pathak dpathak1...@gmail.com wrote: ** So why can't we just create the necessary active links to impose those restrictions each time someone searches or tries to view / modify a change or incident? These can just be custom objects and when you put the form in search mode you could automatically restrict the search . Other than the complexity to derive the access restrictions I don't see any other downside to it. Am I incorrect ? Sent from my iPhone On Oct 3, 2013, at 11:32 PM, Ray Gellenbeck raygellenb...@yahoo.com wrote: ** Agreed. We'd prefer the ability to say... This group's tickets are invisible to everyone else, including sister support teams within our company and other companies. This data in CMDB can be seen by all in our company, but not others. This data in CMDB can be seen by all companies These support KB articles are only for NOC people. These SRM catalog entries are for all companies except (x) and (y). etc In Sony's case, we'd like to offer the app to other sister divisions while keeping some elements proprietary to ours, but take it a step deeper and say the SOC's tickets cannot be viewed by anyone not in the SOC group(s). I have played with 8.1 in a dev sandbox but not delved into multi-tenancy changes yet. In 7.6.04, the model was insufficient in complexity/options to allow this efficiently. Ray Gellenbeck Mgr, BSM Sony Network Entertainment Int'l San Diego, CA -- *From:* John Marshall marsh...@gmail.com *To:* arslist@ARSLIST.ORG *Sent:* Thursday, October 3, 2013 8:46 AM *Subject:* Re: Support Company based muti-tenancy ** Hi Ryan, I think that this phrase sums up perfectly what multi-tenancy is “Tenancy is based and controlled at the Company level”. However, I think for my issue I would like multi-tenancy to be defined as “Tenancy is based and controlled at the _Organizational_ level while allowing access to company level data” Here is what I _think_ the issues would still be trying to setup the system with support users having unrestricted access and the end users having access to specific companies. 1. If I give the support users Unrestricted Access then all the support users will see ALL the tickets in the other organization’s area and we only want them to see items in their area 2. End users belong to an overarching company of which all the other (support) organizations are children of that company, so end users will belong to that overarching company vs. a specific “sub company” (organization) Let me see if I can give a use case based on what I really want to do... I work at GWU and ALL the users (end users and support users) will need to belong to the company GWU. I also have 2 organizations, IT and AT, that want to be able to be completely autonomous from one another but still use the same user base (GWU users). I would like to setup the support user in the IT group to belong to a IT “company/org” and the AT support users belong to a AT “company/org” So when a user calls IT to report an issue, I would like the IT people to be able to a) Retrieve the user records from the GWU pool of users (which we can with Support Company Access Config) b) Have the business rules for IT be used to process the ticket. c) Not have the AT group be able to see the tickets that belong to IT Then I would like the same to happen for the AT group when a user calls AT to report an issue. I think the highest priority is based on Incident and Problem, but this would need to cascade to the other ITSM modules as well Again, thanks for the input. Hopefully the above clears up a little bit what I am looking for, however I think that might not be something that can be done with just configuration options (but I am hoping to be proven wrong) John On Thu, Oct 3, 2013 at 9:53 AM, Downing, Ryan ryan_down...@bmc.comwrote: ** Hi John, ** ** If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: ** ** 1. Support people have Unrestricted Access 2. End users have Restricted Access to the Company (department) to which they belong ** ** In ITSM 8.1 multi-tenancy works as follows: ** ** **Ø **Multi-tenancy is a feature in the BMC Remedy Applications that enables you to control which records
Re: Support Company based muti-tenancy
Got it. Makes sense if users have those kinds of access and are not limited to just the web access. Thanks for the reply. :) Deepak Sent from my iPhone On Oct 9, 2013, at 5:47 PM, LJ LongWing lj.longw...@gmail.com wrote: ** One down side to it is that active links are only client side. If these people shouldn't have access to the data, then it needs to not even be filters...it needs to be permissions. Active Links would stop someone from getting the form openbut what about searches in consoles that show the data? What about the ODBC/JDBC reporting capabilitiesthose don't fire workflow...they just use permissions to access data. Active Links would provide one layer of 'stop'...but it would only be one, and it would be overall ineffective in the entire system. On Wed, Oct 9, 2013 at 4:43 PM, Deepak Pathak dpathak1...@gmail.com wrote: ** So why can't we just create the necessary active links to impose those restrictions each time someone searches or tries to view / modify a change or incident? These can just be custom objects and when you put the form in search mode you could automatically restrict the search . Other than the complexity to derive the access restrictions I don't see any other downside to it. Am I incorrect ? Sent from my iPhone On Oct 3, 2013, at 11:32 PM, Ray Gellenbeck raygellenb...@yahoo.com wrote: ** Agreed. We'd prefer the ability to say... This group's tickets are invisible to everyone else, including sister support teams within our company and other companies. This data in CMDB can be seen by all in our company, but not others. This data in CMDB can be seen by all companies These support KB articles are only for NOC people. These SRM catalog entries are for all companies except (x) and (y). etc In Sony's case, we'd like to offer the app to other sister divisions while keeping some elements proprietary to ours, but take it a step deeper and say the SOC's tickets cannot be viewed by anyone not in the SOC group(s). I have played with 8.1 in a dev sandbox but not delved into multi-tenancy changes yet. In 7.6.04, the model was insufficient in complexity/options to allow this efficiently. Ray Gellenbeck Mgr, BSM Sony Network Entertainment Int'l San Diego, CA From: John Marshall marsh...@gmail.com To: arslist@ARSLIST.ORG Sent: Thursday, October 3, 2013 8:46 AM Subject: Re: Support Company based muti-tenancy ** Hi Ryan, I think that this phrase sums up perfectly what multi-tenancy is “Tenancy is based and controlled at the Company level”. However, I think for my issue I would like multi-tenancy to be defined as “Tenancy is based and controlled at the _Organizational_ level while allowing access to company level data” Here is what I _think_ the issues would still be trying to setup the system with support users having unrestricted access and the end users having access to specific companies. 1. If I give the support users Unrestricted Access then all the support users will see ALL the tickets in the other organization’s area and we only want them to see items in their area 2. End users belong to an overarching company of which all the other (support) organizations are children of that company, so end users will belong to that overarching company vs. a specific “sub company” (organization) Let me see if I can give a use case based on what I really want to do... I work at GWU and ALL the users (end users and support users) will need to belong to the company GWU. I also have 2 organizations, IT and AT, that want to be able to be completely autonomous from one another but still use the same user base (GWU users). I would like to setup the support user in the IT group to belong to a IT “company/org” and the AT support users belong to a AT “company/org” So when a user calls IT to report an issue, I would like the IT people to be able to a) Retrieve the user records from the GWU pool of users (which we can with Support Company Access Config) b) Have the business rules for IT be used to process the ticket. c) Not have the AT group be able to see the tickets that belong to IT Then I would like the same to happen for the AT group when a user calls AT to report an issue. I think the highest priority is based on Incident and Problem, but this would need to cascade to the other ITSM modules as well Again, thanks for the input. Hopefully the above clears up a little bit what I am looking for, however I think that might not be something that can be done with just configuration options (but I am hoping to be proven wrong) John On Thu, Oct 3, 2013 at 9:53 AM, Downing, Ryan ryan_down...@bmc.com wrote: ** Hi John, If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: 1. Support people have Unrestricted Access 2. End users have
Re: Support Company based muti-tenancy
I have used a filter on GET to stop ODBC access before. I agree permissions are the way to go but ODBC can fire workflow on GET. On Wed, Oct 9, 2013 at 3:47 PM, LJ LongWing lj.longw...@gmail.com wrote: ** One down side to it is that active links are only client side. If these people shouldn't have access to the data, then it needs to not even be filters...it needs to be permissions. Active Links would stop someone from getting the form openbut what about searches in consoles that show the data? What about the ODBC/JDBC reporting capabilitiesthose don't fire workflow...they just use permissions to access data. Active Links would provide one layer of 'stop'...but it would only be one, and it would be overall ineffective in the entire system. On Wed, Oct 9, 2013 at 4:43 PM, Deepak Pathak dpathak1...@gmail.comwrote: ** So why can't we just create the necessary active links to impose those restrictions each time someone searches or tries to view / modify a change or incident? These can just be custom objects and when you put the form in search mode you could automatically restrict the search . Other than the complexity to derive the access restrictions I don't see any other downside to it. Am I incorrect ? Sent from my iPhone On Oct 3, 2013, at 11:32 PM, Ray Gellenbeck raygellenb...@yahoo.com wrote: ** Agreed. We'd prefer the ability to say... This group's tickets are invisible to everyone else, including sister support teams within our company and other companies. This data in CMDB can be seen by all in our company, but not others. This data in CMDB can be seen by all companies These support KB articles are only for NOC people. These SRM catalog entries are for all companies except (x) and (y). etc In Sony's case, we'd like to offer the app to other sister divisions while keeping some elements proprietary to ours, but take it a step deeper and say the SOC's tickets cannot be viewed by anyone not in the SOC group(s). I have played with 8.1 in a dev sandbox but not delved into multi-tenancy changes yet. In 7.6.04, the model was insufficient in complexity/options to allow this efficiently. Ray Gellenbeck Mgr, BSM Sony Network Entertainment Int'l San Diego, CA -- *From:* John Marshall marsh...@gmail.com *To:* arslist@ARSLIST.ORG *Sent:* Thursday, October 3, 2013 8:46 AM *Subject:* Re: Support Company based muti-tenancy ** Hi Ryan, I think that this phrase sums up perfectly what multi-tenancy is “Tenancy is based and controlled at the Company level”. However, I think for my issue I would like multi-tenancy to be defined as “Tenancy is based and controlled at the _Organizational_ level while allowing access to company level data” Here is what I _think_ the issues would still be trying to setup the system with support users having unrestricted access and the end users having access to specific companies. 1. If I give the support users Unrestricted Access then all the support users will see ALL the tickets in the other organization’s area and we only want them to see items in their area 2. End users belong to an overarching company of which all the other (support) organizations are children of that company, so end users will belong to that overarching company vs. a specific “sub company” (organization) Let me see if I can give a use case based on what I really want to do... I work at GWU and ALL the users (end users and support users) will need to belong to the company GWU. I also have 2 organizations, IT and AT, that want to be able to be completely autonomous from one another but still use the same user base (GWU users). I would like to setup the support user in the IT group to belong to a IT “company/org” and the AT support users belong to a AT “company/org” So when a user calls IT to report an issue, I would like the IT people to be able to a) Retrieve the user records from the GWU pool of users (which we can with Support Company Access Config) b) Have the business rules for IT be used to process the ticket. c) Not have the AT group be able to see the tickets that belong to IT Then I would like the same to happen for the AT group when a user calls AT to report an issue. I think the highest priority is based on Incident and Problem, but this would need to cascade to the other ITSM modules as well Again, thanks for the input. Hopefully the above clears up a little bit what I am looking for, however I think that might not be something that can be done with just configuration options (but I am hoping to be proven wrong) John On Thu, Oct 3, 2013 at 9:53 AM, Downing, Ryan ryan_down...@bmc.comwrote: ** Hi John, ** ** If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: ** ** 1. Support people have Unrestricted Access 2. End users have Restricted Access to the Company
Re: Support Company based muti-tenancy
John I've run into this at a couple of sites, and the problem has ALWAYS been the common user base. Never had a solution that didn't involve tinkering with the code to change the default behavior of multi-tenancy's additive permission model. -- Thank You, Chris Danaceau FINRA 240-386-6728 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Marshall Sent: Monday, September 30, 2013 2:28 PM To: arslist@ARSLIST.ORG Subject: Support Company based muti-tenancy I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated to the customer's company. Any ideas/suggestions on how to force it to be the support person’s company (department) rules, again, short of coding changes? Thanks for any help/ideas/etc. John ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years Confidentiality Notice: This email, including attachments, may include non-public, proprietary, confidential or legally privileged information. If you are not an intended recipient or an authorized agent of an intended recipient, you are hereby notified that any dissemination, distribution or copying of the information contained in or transmitted with this e-mail is unauthorized and strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and permanently delete this e-mail, its attachments, and any copies of it immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Support Company based muti-tenancy
** It would be nice if the concept of Hierachial Groups (ARS 8.X) was implemented within ITSM 8.X, but I guess that would be for a future release (ITSM 9.X) ? Terry on Oct 04, 2013, Ray Gellenbeck raygellenb...@yahoo.com wrote: ** Agreed. We'd prefer the ability to say... "This group's tickets are invisible to everyone else, including sister support teams within our company and other companies. This data in CMDB can be seen by all in our company, but not others. This data in CMDB can be seen by all companies These support KB articles are only for NOC people. These SRM catalog entries are for all companies except (x) and (y). etc" In Sony's case, we'd like to offer the app to other sister divisions while keeping some elements proprietary to ours, but take it a step deeper and say "the SOC's tickets cannot be viewed by anyone not in the SOC group(s)." I have played with 8.1 in a dev sandbox but not delved into multi-tenancy changes yet. In 7.6.04, the model was insufficient in complexity/options to allow this efficiently. Ray Gellenbeck Mgr, BSM Sony Network Entertainment Int'l San Diego, CA From: John Marshall marsh...@gmail.com To: arslist@ARSLIST.ORG Sent: Thursday, October 3, 2013 8:46 AM Subject: Re: Support Company based muti-tenancy ** Hi Ryan, I think that this phrase sums up perfectly what multi-tenancy is Tenancy is based and controlled at the Company level. However, I think for my issue I would like multi-tenancy to be defined as Tenancy is based and controlled at the _Organizational_ level while allowing access to company level data Here is what I _think_ the issues would still be trying to setup the system with support users having unrestricted access and the end users having access to specific companies. 1. If I give the support users "Unrestricted Access" then all the support users will see ALL the tickets in the other organizations area and we only want them to see items in their area 2. End users belong to an overarching company of which all the other (support) organizations are children of that company, so end users will belong to that overarching company vs. a specific sub company (organization) Let me see if I can give a use case based on what I really want to do... I work at GWU and ALL the users (end users and support users) will need to belong to the company "GWU". I also have 2 organizations, IT and AT, that want to be able to be completely autonomous from one another but still use the same user base (GWU users). I would like to setup the support user in the IT group to belong to a IT company/org and the AT support users belong to a AT company/org So when a user calls IT to report an issue, I would like the IT people to be able to a) Retrieve the user records from the GWU pool of users (which we can with Support Company Access Config) b) Have the business rules for IT be used to process the ticket. c) Not have the AT group be able to see the tickets that belong to IT Then I would like the same to happen for the AT group when a user calls AT to report an issue. I think the highest priority is based on Incident and Problem, but this would need to cascade to the other ITSM modules as well Again, thanks for the input. Hopefully the above clears up a little bit what I am looking for, however I think that might not be something that can be done with just configuration options (but I am hoping to be proven wrong) John On Thu, Oct 3, 2013 at 9:53 AM, Downing, Ryan ryan_down...@bmc.com wrote: ** Hi John, If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: 1. Support people have "Unrestricted Access" 2. End users have "Restricted Access" to the Company (department) to which they belong In ITSM 8.1 multi-tenancy works as follows: Multi-tenancy is a feature in the BMC Remedy Applications that enables you to control which records and specific configuration data are exposed to a user, based on the users permissions. Tenancy is based and controlled at the Company level. Various forms in the BMC Remedy Applications expose one or more Company fields that control the tenancy access for a given record. Row-level security typically works as follows: o On main user facing transactional forms: Tenancy is based on the Customer Company and/or Process Company defined on the record (sets field 112) Tenancy is also based on the Support Companies assigned to a record (sets field 60900) o Child forms: Child form should inherit their parents tenancy permissions o Join forms Tenancy should be inherited from either the primary or secondary form identified within the join criteria especially if one of the forms is a user facing transactional form Tenancy is implemented using the Row-level Security feature of AR. In summary we determine which groups or roles have access to a request through the permissions on the Request ID field (
Re: Support Company based muti-tenancy
John, When we went to 7.5 a few years ago we wanted to do the same exact thing. We made some coding changes but, for various reasons, it was never entirely satisfactory. Once you start tinkering it’s a very slippery slope. We’re in the process of upgrading to 8.1 so will be re-visiting the issue to see if we can’t come up with some fresh ideas. Rebecca On Mon, Sep 30, 2013 at 2:27 PM, John Marshall marsh...@gmail.com wrote: I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated to the customer's company. Any ideas/suggestions on how to force it to be the support person’s company (department) rules, again, short of coding changes? Thanks for any help/ideas/etc. John ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years -- Rebecca Boyd Application Administrator Wake Forest University ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Support Company based muti-tenancy
Hi John, If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: 1. Support people have Unrestricted Access 2. End users have Restricted Access to the Company (department) to which they belong In ITSM 8.1 multi-tenancy works as follows: Ø Multi-tenancy is a feature in the BMC Remedy Applications that enables you to control which records and specific configuration data are exposed to a user, based on the user’s permissions. Tenancy is based and controlled at the Company level. Various forms in the BMC Remedy Applications expose one or more Company fields that control the tenancy access for a given record. Ø Row-level security typically works as follows: o On main user facing transactional forms: § Tenancy is based on the Customer Company and/or Process Company defined on the record (sets field 112) § Tenancy is also based on the Support Companies assigned to a record (sets field 60900) o Child forms: § Child form should inherit their parents tenancy permissions o Join forms § Tenancy should be inherited from either the primary or secondary form identified within the join criteria especially if one of the forms is a user facing transactional form Ø Tenancy is implemented using the Row-level Security feature of AR. In summary we determine which groups or roles have access to a request through the permissions on the Request ID field (field ID 1). - In the Remedy Applications this is controlled by the following permissions on field ID 1 § 10 = Unrestricted Access § 7 = Assignee Groups (field 112) § 60900 = Vendor Assignee Groups (field 60900, typically only used for transactional based forms) - These permissions are used to drive the tenancy model in the apps. Both Assignee Groups and Vendor Assignee Groups are referred to as Implicit Groups in AR. - In the apps we assign Company permission groups to these two Implicit Groups to control access to records. Hence our tenancy model is based on Company access. Unrestricted Access permission group is a regular AR permission group. If a form is going to be row-level secured in the Apps (or multi-tenant) we typically assign these three permission groups to field ID 1 on that form. Note, Vendor Assignee Groups (field 60900) typically contains the AR permissions group ID for Support Companies that are assigned to a record (e.g. for Incident that would be the Assigned and Owner Support Company; for Change that would be the Change Coordinator and Manager Support Company, etc.). The Vendor Assignee Groups permission is not required on all forms and it typically found on transactional based forms. - So in order for a user to see a record, on a form that is multi-tenant, they need to either have the Unrestricted Access permission group, which gives them access to all records as this is defined on field ID 1 on all tenant forms OR they need to have access granted by one of the two Implicit Groups. You’re use case in ITSM 8.1 would mean that the customer company is stored in field 112 (Assignee Groups) and the support user company is stored in field 60900 (Vendor Assignee Groups) (on all main transactional forms: incident, problem, change…etc…). Since Field ID 1 on these forms has permissions to both field 112 and 60900 the appropriate people should see the request. Support users should be allowed to see all requests as they have unrestricted access. (hopefully I have understood you’re use case properly ☺) Hope this helps. Regards, Ryan. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Marshall Sent: Monday, September 30, 2013 2:28 PM To: arslist@ARSLIST.ORG Subject: Support Company based muti-tenancy I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated
Re: Support Company based muti-tenancy
Hi Rebecca, You are absolutly right about that being a slippery slope that's why I want to avoid any type of code changes. That 'Compnay' field is one of those kind of important ones in ITSM...oh well, thanks for the input John p.s. I work at George Washington University (the Ashburn VA campus) On Thu, Oct 3, 2013 at 9:12 AM, Boyd, Rebecca boy...@wfu.edu wrote: ** John, When we went to 7.5 a few years ago we wanted to do the same exact thing. We made some coding changes but, for various reasons, it was never entirely satisfactory. Once you start tinkering it’s a very slippery slope. We’re in the process of upgrading to 8.1 so will be re-visiting the issue to see if we can’t come up with some fresh ideas. Rebecca On Mon, Sep 30, 2013 at 2:27 PM, John Marshall marsh...@gmail.com wrote: I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated to the customer's company. Any ideas/suggestions on how to force it to be the support person’s company (department) rules, again, short of coding changes? Thanks for any help/ideas/etc. John ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years -- Rebecca Boyd Application Administrator Wake Forest University _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Support Company based muti-tenancy
Company; for Change that would be the Change Coordinator and Manager Support Company, etc.). The Vendor Assignee Groups permission is not required on all forms and it typically found on transactional based forms. **- **So in order for a user to see a record, on a form that is multi-tenant, they need to either have the Unrestricted Access permission group, which gives them access to all records as this is defined on field ID 1 on all tenant forms OR they need to have access granted by one of the two Implicit Groups. ** ** You’re use case in ITSM 8.1 would mean that the customer company is stored in field 112 (Assignee Groups) and the support user company is stored in field 60900 (Vendor Assignee Groups) (on all main transactional forms: incident, problem, change…etc…). Since Field ID 1 on these forms has permissions to both field 112 and 60900 the appropriate people should see the request. ** ** Support users should be allowed to see all requests as they have unrestricted access. ** ** (hopefully I have understood you’re use case properly J) ** ** Hope this helps. ** ** Regards, Ryan. ** ** ** ** -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of John Marshall Sent: Monday, September 30, 2013 2:28 PM To: arslist@ARSLIST.ORG Subject: Support Company based muti-tenancy ** ** I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… ** ** I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. ** ** I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated to the customer's company. ** ** Any ideas/suggestions on how to force it to be the support person’s company (department) rules, again, short of coding changes? ** ** Thanks for any help/ideas/etc. ** ** John ** ** ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Support Company based muti-tenancy
Agreed. We'd prefer the ability to say... This group's tickets are invisible to everyone else, including sister support teams within our company and other companies. This data in CMDB can be seen by all in our company, but not others. This data in CMDB can be seen by all companies These support KB articles are only for NOC people. These SRM catalog entries are for all companies except (x) and (y). etc In Sony's case, we'd like to offer the app to other sister divisions while keeping some elements proprietary to ours, but take it a step deeper and say the SOC's tickets cannot be viewed by anyone not in the SOC group(s). I have played with 8.1 in a dev sandbox but not delved into multi-tenancy changes yet. In 7.6.04, the model was insufficient in complexity/options to allow this efficiently. Ray Gellenbeck Mgr, BSM Sony Network Entertainment Int'l San Diego, CA From: John Marshall marsh...@gmail.com To: arslist@ARSLIST.ORG Sent: Thursday, October 3, 2013 8:46 AM Subject: Re: Support Company based muti-tenancy ** Hi Ryan, I think that this phrase sums up perfectly what multi-tenancy is “Tenancy is based and controlled at the Company level”. However, I think for my issue I would like multi-tenancy to be defined as “Tenancy is based and controlled at the _Organizational_ level while allowing access to company level data” Here is what I _think_ the issues would still be trying to setup the system with support users having unrestricted access and the end users having access to specific companies. 1. If I give the support users Unrestricted Access then all the support users will see ALL the tickets in the other organization’s area and we only want them to see items in their area 2. End users belong to an overarching company of which all the other (support) organizations are children of that company, so end users will belong to that overarching company vs. a specific “sub company” (organization) Let me see if I can give a use case based on what I really want to do... I work at GWU and ALL the users (end users and support users) will need to belong to the company GWU. I also have 2 organizations, IT and AT, that want to be able to be completely autonomous from one another but still use the same user base (GWU users). I would like to setup the support user in the IT group to belong to a IT “company/org” and the AT support users belong to a AT “company/org” So when a user calls IT to report an issue, I would like the IT people to be able to a) Retrieve the user records from the GWU pool of users (which we can with Support Company Access Config) b) Have the business rules for IT be used to process the ticket. c) Not have the AT group be able to see the tickets that belong to IT Then I would like the same to happen for the AT group when a user calls AT to report an issue. I think the highest priority is based on Incident and Problem, but this would need to cascade to the other ITSM modules as well Again, thanks for the input. Hopefully the above clears up a little bit what I am looking for, however I think that might not be something that can be done with just configuration options (but I am hoping to be proven wrong) John On Thu, Oct 3, 2013 at 9:53 AM, Downing, Ryan ryan_down...@bmc.com wrote: ** Hi John, If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: 1. Support people have Unrestricted Access 2. End users have Restricted Access to the Company (department) to which they belong In ITSM 8.1 multi-tenancy works as follows: Ø Multi-tenancy is a feature in the BMC Remedy Applications that enables you to control which records and specific configuration data are exposed to a user, based on the user’s permissions. Tenancy is based and controlled at the Company level. Various forms in the BMC Remedy Applications expose one or more Company fields that control the tenancy access for a given record. Ø Row-level security typically works as follows: o On main user facing transactional forms: § Tenancy is based on the Customer Company and/or Process Company defined on the record (sets field 112) § Tenancy is also based on the Support Companies assigned to a record (sets field 60900) o Child forms: § Child form should inherit their parents tenancy permissions o Join forms § Tenancy should be inherited from either the primary or secondary form identified within the join criteria especially if one of the forms is a user facing transactional form Ø Tenancy is implemented using the Row-level Security feature of AR. In summary we determine which groups or roles have access to a request through the permissions on the Request ID field (field ID 1). - In the Remedy Applications this is controlled by the following permissions on field ID 1 § 10 = Unrestricted Access § 7 = Assignee Groups (field 112) § 60900 = Vendor Assignee
Re: Support Company based muti-tenancy
Oh yea, I forgot to mention we are running on ARS/ITSM 8.1 Patch 2 with Windows 2008 and MS SQL 2008 Thanks John ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Support Company based muti-tenancy
I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated to the customer's company. Any ideas/suggestions on how to force it to be the support person’s company (department) rules, again, short of coding changes? Thanks for any help/ideas/etc. John ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
