Dave,
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.
V/R,
Brian
From: ARSList On Behalf Of Dave Barber
Sent: Tuesday, July 23, 2019 5:17 AM
To: ARSList
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 10 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.
Regards
Dave
On Mon, 22 Jul 2019 at 15:42, LJ LongWing
mailto:lj.longw...@gmail.com>> wrote:
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 iddid
you miss that by chance?
On Mon, Jul 22, 2019 at 2:59 AM Dave Barber
mailto:daddy.bar...@gmail.com>> 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
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
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 mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
