Irina, OK, using an older version, I have a number of customers who played the following trick to isolate a class of tickets….
Step 1 – Create a new company – say Company-HR. Step 2 – Remove everyone from Unrestricted Access and tie them to a company. So, your IT team will be only in Company but you put your HR team in Company AND Company-HR (so, your HR team can see IT tickets, if that is not OK, do this same process creating a Company-IT additional company and do these steps for all IT tickets). NOTE: It is important that people remain in Company as that is where their catalog and other things are. They ARE NOT changing what company they are in, they are just being given access to tickets from another company. Step 3 – Add a filter that whenever a ticket is submitted that is an HR ticket, you change the Company field from Company to Company-HR. This leaves everyone in Company so that they can see menus and get catalog items and such. YOU DO NOT create catalog items for the new dummy companies. They exist only to allow bucketing and holding tickets. You may need to configure some menus and such for the dummy company(ies) to allow work on the tickets, but for the most part you should not have to worry about it. You are simply redirecting to a dummy company all HR tickets here so that they are no longer accessible by somone in Company but only those in Company-HR. No one will have Unrestricted Access so no one can see across company boundaries. This is really a quick and dirty version of using support group centric with hierarchy row level security that is fully supported in 9.1 and later. I hope this helps, Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Irina Solarcuka Sent: Friday, April 21, 2017 11:22 AM To: [email protected] Subject: Re: How to "split" Unrestricted Access ** Hi Doug, I'm using ITSM 8.1.02 /Irina 2017-04-21 21:02 GMT+03:00 Mueller, Doug <[email protected]<mailto:[email protected]>>: ** Irina, You did not mention the version of the ITSM applications that you are using. In the 9.1 release (and I suggest the sp2 or later release), there were some adjustments made to the security model of ITSM. It is configurable to use the new vs. old security model (configuration option available in the sp2 and later release). The options are to make the security Company centric (the old model) or to make it Support Group centric (the new model). In addition, the Hierarchical group feature of the AR System is fully supported within the ITSM applications. So, with this approach, what you would do is have support groups that are for IT tickets and support groups that are for HR tickets. You can then link them up with parent groups (and you can have multiple levels) and roll up to an IT-ALL ACCESS and an HR-ALL ACCESS group respectively. Then, you add IT users to IT-ALL ACCESS and HR users to HR-ALL ACCESS and no one has Unrestricted Access. This way, all IT users can access all IT tickets – but no HR tickets. HR users can access all HR tickets – but no IT tickets. If someone can see across things, they can be in both parent groups – or Unrestricted Access. The key is that what you are trying to accomplish is OOTB functionality with the new security model option available in the 9.1 sp2 or later releases. Something to look at to see how it can solve your problem at a minimum. Then, something to consider upgrading to is that does indeed solve the problem you are looking at. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Brian Pancia Sent: Friday, April 21, 2017 6:57 AM To: [email protected]<mailto:[email protected]> Subject: Re: How to "split" Unrestricted Access ** Irina, I would recommended cleaning everything up and moving to a multi-tenancy model. Unrestricted Access should be used sparingly and shouldn't be given to everyone. I normally treat that as an admin function or for auditing. Multi-tenancy is exactly what you are asking for and is out of box functionality, no customizations required. If you try to customize a solution now you will probably regret it in the future. What happens when facilities or security want to come on board and have the same data restriction requirements? Don't over think it and make a complicated solution. Too many developers destroy systems by coming up with solutions that out of box functionality can handle. Think of patches, upgrades, onboarding new customers. Brian ________________________________ From: Action Request System discussion list(ARSList) <[email protected]<mailto:[email protected]>> on behalf of Murnane, Phil <[email protected]<mailto:[email protected]>> Sent: Friday, April 21, 2017 8:14:09 AM To: [email protected]<mailto:[email protected]> Subject: Re: How to "split" Unrestricted Access ** Hello Irina, Most HR applications I've seen store their records in separate tables from non-HR records, partly to make the security scheme simpler. If this is not an option for you, I can think of one solution but it's not a good one at all: add two filters to the Incident form that fire On Get. The first checks for membership in the "HR Incidents" group and stores the result of the check in a display-only field. The second sets the value of all fields to null if the membership check fails. This is very ugly because of 1) the extra load on the system to process all the On Get actions and 2) because a query would still know that a record exists, but would not know the content of the record. Also, the OOB workflows will need a lot of fix-up. FWIW, --Phil ________________________________ From: Action Request System discussion list(ARSList) <[email protected]<mailto:[email protected]>> on behalf of Irina Solarcuka <[email protected]<mailto:[email protected]>> Sent: Friday, April 21, 2017 5:18 AM To: [email protected]<mailto:[email protected]> Subject: Re: How to "split" Unrestricted Access ** Hi, The issue is that all support groups members has unrestricted access and I can't remove that. It is a reason why I need "another unrestricted access" that allows to HR people to see only their incidents. At the same time I need to limit an existing Unrestricted Access so that people can see only non-HR incidents. BR, Irina 2017-04-21 11:33 GMT+03:00 Chris Jones <[email protected]<mailto:[email protected]>>: ** Hi Irina, Another option for you to consider is using parent groups to control access to multiple companies, etc. https://docs.bmc.com/docs/display/public/ars81/Using+a+parent+group+for+permissions+inheritance Maybe you could create an HR parent group and grant access to that so HR people are granted access to anything within this parent group? Regards, Chris Chris Jones, Director www.aramea.co<http://www.aramea.co/> From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Irina Solarcuka Sent: 21 April 2017 05:34 To: [email protected]<mailto:[email protected]> Subject: How to "split" Unrestricted Access ** Hi, I would like to "split" Unrestricted Access in two parts - HR Unrestricted Access and Unrestricted Access for the other incidents. Is it possible? I've created an additional field in CTM:People form called HR Unrestricted Access, an additional Role and group with the same name. I can't use multi-tenancy since we have a mix of customers and support companies. Each support company can support each customer. I can't remove Unrestricted access from all the users that have that because of the same reason.. Any help is appreciated BR, Irina _ARSlist: "Where the Answers Are" and have been for 20 years_ ________________________________ [Image removed by sender. Avast logo]<https://www.avast.com/antivirus> This email has been checked for viruses by Avast antivirus software. www.avast.com<https://www.avast.com/antivirus> _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_ DISCLAIMER: The information contained in this e-mail and its attachments contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are notified that any disclosure, copying, distribution or action in reliance upon the contents of the information transmitted is strictly prohibited. If you have received this information in error, please delete it immediately. _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"
