[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

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.

Regards

Dave

On Mon, 22 Jul 2019 at 15:42, LJ LongWing <lj.longwing@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 id....did you miss that by chance?

On Mon, Jul 22, 2019 at 2:59 AM Dave Barber <daddy.barber@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