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 <[email protected]> To: [email protected] 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 <[email protected]> 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 >§ 1000000000 = 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 J) > >Hope this helps. > >Regards, >Ryan. > > >-----Original Message----- >From: Action Request System discussion list(ARSList) >[mailto:[email protected]] On Behalf Of John Marshall >Sent: Monday, September 30, 2013 2:28 PM >To: [email protected] >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_ _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"
