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.
You already got the solution from Doug and I. Doug of course spelled it out much nicer than I did.
Step 1 – Stop using Unrestricted Access
Step 2 – Stop writing code to disable Unrestricted Access. Developing SQL scripts and code on field 112 is not going to help with Unrestricted Access. This is unnecessary customizations and could have a negative impact on future needs
of the system. See Step 1 for clarification.
Step 3 – Draw out your permission scenarios out on a white board. You could setup a parent company to the 2 companies you want restricted access to and then assign people to that parent company. This will give members of the parent company
access to all assets for the 2 companies. If you only want a small subset of assets visible by the special group, then look at setting up a separate operating company and have those assets supported by them or setup a special customer company and have those
assets assigned to the special company.
This should be basic configuration. Most organizations do not setup their companies and permission structures properly. Sooner or later they run into issues like you are running into. Using Unrestricted Access for anyone outside a small
set of users like admins and auditors is such a bad idea. You said your problem was trying to figure out a way around Unrestricted Access and the simple answer is stop using Unrestricted Access.
From: ARSList <firstname.lastname@example.org> On Behalf Of
Sent: Tuesday, July 23, 2019 5:17 AM
To: ARSList <email@example.com>
Subject: Re: Atrium and field 112
LJ/To all of you who have answered so far, many thanks for persevering with me and attempting to guide me.
With regards dynamic groups, request ID in Base Element would require further permissions added beyond the existing Assignee Group, CMDB Data Change All, CMDB Data View All, CMDB Write Security Parent Group and Hierarchical Group?
The change and CMDB components, whilst on the same platform, are not really linked as such - separate users, albeit in the same logical company. They are purely using the CMDB for managing the various assets, they won't be raising changes against them. No
actual customers have access to either the CMDB or Change applications/data. For reference, there are 2 companies that would have restricted CIs, out of around 3,200 companies.
Currently we are purely using the "standard" 9.1 permissions, nothing custom, no hierarchical groups, no parents, etc. - this is the first time that we have looked into any form of modification of the permissions.
The process I had initially tried to restrict visibility of the CIs for a specific company was using a little SQL to replace the 1000000000 entry ("Unrestricted Access") in field 112 on base element with another (custom) group. Very simple workflow, the values
in field 112 were correctly amended, it's just that the revised permissions don't actually work.
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?
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?
ARSList mailing list
ARSList mailing list