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 <[email protected]> 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 <[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_ > > > _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"
