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 open....but what about searches in consoles that show the > data? What about the ODBC/JDBC reporting capabilities....those 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 "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: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_ >>> >>> _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_ > > _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"
