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