Dave, First, let’s take a look at what you are trying to accomplish.
If I understand correctly, you have a situation where you have many (100s to 1000s) of customer companies. You want your support staff to have access to all of them – well, almost all…. Your message was referencing CIs in the CMDB, but you didn’t mention Changes. Are you restricting access to the Changes as well or is it only the CIs? If you allow access to Changes but not the CIs that are related, that seems kind of unusual. So, are you really trying to allow access to many companies but not all and then control the access to the few more closely? The best approach for this is to take advantage of the hierarchical group feature of the system. This should all work cleanly and completely in the current versions of the product. Unfortunately, there are a few issues still with version 9.1.02 – Check the release notes for more recent versions to check on the fixes/updates made in later versions to see if any of the fixes are significant for you. Say you have 1000 companies. You want everyone to have access to say 975 of these companies but 25 have special restrictions. Step 1 – Create a group that is all the “all access” companies. Make it the parent company of the 975 companies who everyone has access to. Step 2 – Do the restricted companies all allow access to a subset of your staff or is each one unique? If there is a subset who can see all the special companies, then create another group called “special companies” and make the 25 companies have that company as the parent. If each of the special companies has different people with access, that is OK, as you have the individual groups. Step 3 – DO NOT have your staff have Unrestricted Access – because you really don’t want them to have unrestricted access. You really want to restrict their access….. (OK, if there are some people who should have really unrestricted access, leave them with this access) Step 4 – Make everyone a member of the “all access” companies parent group that you defined above Step 5 – For any user (who is not unrestricted) who has access to all special companies, make them members of the “special companies” group. For any user who has access to some specific special companies but not all of them, make them members of the specific company group(s). Step 6 – Just as a reminder, make sure that the hierarchical group feature is turned on….. (should be by default, but make sure you didn’t turn it off) This should solve things for you. The very limited to no users who have unrestricted access have access to everything. All customer have access to all customers who are general access have that access by being in the one parent group. Other users who have additional companies they have access to by additional group(s) have access to those extra groups too. This controls access to the CIs AND the Changes and any other aspects of ITSM that you are using. Now, if what you are trying to accomplish is different, then we need more detail of what you are attempting to accomplish to help. n Description of exactly what you need – CIs only or changes too? n Permissions that you have set on the Entry ID field of CIs n Data you have in any row-level security field (112 or any other) n Do you have hierarchical groups in use and if so, are any groups involved in any hierarchy I hope this offers some ideas, Doug Mueller From: ARSList [mailto:[email protected]] On Behalf Of LJ LongWing Sent: Monday, July 22, 2019 7:41 AM To: ARSList <[email protected]> Subject: [EXTERNAL] Re: Atrium and field 112 Dave, When implementing dynamic permission groups, you need to ensure that the field you are using not only needs to be in that field, but also in request id....did you miss that by chance? On Mon, Jul 22, 2019 at 2:59 AM Dave Barber <[email protected]<mailto:[email protected]>> wrote: All, This is on ARS 9.1.02. We have a range of users making use of both Atrium and Change Management. We have a range of CIs uploaded against a large number of compaies, and users have always been given unrestricted access. A recent requirement has involved us wanting to restrict visibility of some CIs to specific users. Multi tenancy would not be viable (as there are hundreds of companies within our system), so I had thought that replacing the value for "Unrestricted Access" in field 112 in Base Element for the relevant CIs with another permissions group, and adding that permissions group to the required users would have the desired effect. It does not work - profiles without the new permissions group can still see the "locked down" CIs. Has anyone else implemented anything along these lines? Regards Dave Barber -- ARSList mailing list [email protected]<mailto:[email protected]> https://mailman.rrr.se/cgi/listinfo/arslist<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=zYKHGihF4icDlNsgMPf82JYjjdgAtCBU4XE4_sOizQo&m=DJOSyymvNN3qPBQFkFALnhBM55_EEem6WfT8L1hcyh4&s=NTONUau3ZsSKV9gp8rllvr-eUvjFGqtREcXju-G_G58&e=>
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
