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.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
> id....did you miss that by chance?
>
> On Mon, Jul 22, 2019 at 2:59 AM Dave Barber <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
>
--
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist
