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

Re: Atrium and field 112



Hi Dave,

The easiest way to prove it's not a cache issue is to 
  1. Stop tomcat on the mid-tier
  2. Delete the cache files in the .../webapps/arsys/cache/... folder
  3. Start tomcat
  4. Re-test
I ran into something like this years ago when permissions changes to the system weren't being honored by the mid-tier.

HTH,
--Phil


From: ARSList <arslist-bounces@arslist.org> on behalf of Dave Barber <daddy.barber@gmail.com>
Sent: Monday, July 22, 2019 8:50 AM
To: ARSList <arslist@arslist.org>
Subject: Re: Atrium and field 112
 
I'm really not sure - my main knowledge of field 112 is from an in-house developed application where we lock down data.  In 10 years of usage of Atrium we've never had any need for locking anything down.

The value that was in Base Element was :
;<numeric related to the "customer company">;1000000000;

I've amended the 1000000000 value to a new permissions group for a couple of CIs, and a profile that doesnt have the new permissions group or any form of Admin rights (other than Asset Viewer) can still find the CI in searches.

Have had issues with mid tier caching, but never experienced issues related to caching and permissions - guidance welcome!

On Mon, 22 Jul 2019 at 13:33, Phil Murnane <phil.murnane@windward.com> wrote:
Any chance that the symptom is due to a caching issue of some sort?


From: ARSList <arslist-bounces@arslist.org> on behalf of Dave Barber <daddy.barber@gmail.com>
Sent: Monday, July 22, 2019 4:57 AM
To: ARSList <arslist@arslist.org>
Subject: Atrium and field 112
 
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