Hi,
That is interesting to hear.
There are plans to install SP3 here, but this will probably be a while
before they get to it.
I guess that way to match a users group-mask against the cache will still
work the same way. In other words it will still strip away any None-groups
before doing the matching.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> I'd be curious to know what you see with this in SP3, since as near as I
> can tell it made significant changes to how the mid-tier ehcache handles
> users and groups, and changed prefetch from push to pull.
>
> Christopher Strauss, Ph.D.
> Call Tracking Administration Manager
> University of North Texas Computing & IT Center
> http://itsm.unt.edu/
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
> Sent: Tuesday, March 13, 2012 8:30 AM
> To: arslist@ARSLIST.ORG
> Subject: Mid-Tier Caching Endeavors
>
> Hi all Mid-Tier Admins!
>
> I have had a series of frustrating issues with Mid-Tier 7.6.04 SP2
> caching, that I think I have now come to grips with.
>
> What I did was to create a Group (STUGUN) and a Role (STUGUN) to be used
> in customization of the application "Remedy Incident Management". The role
> granted access to a set of ACTLs.
>
> What happened was that Mid-Tier failed to recache things sometimes, and
> some users with this group (STUGUN) got access to the ACTLs, and some did
> not.
>
> The same user could get different results depending on which Mid-Tier he
> accessed.
>
> My error, I think, is that the STUGUN-Group was set defined as a
> None-Group.
>
> As it was mapped to a Role, it worked fine to assign permission to it, and
> it also worked fine in Remedy User.
>
> When Mid-Tier does its caching, it will create a unique Group-combination
> based on each users unique combination of Groups.
>
> For example if a user belongs to:
>
> 20213 => Service Request User (Change)
>
> 10001 => STUGUN (None, this is my group)
>
> 20003 => Incident User (Change)
>
> 20000 => General Access (Change)
>
> 20032 => Asset Viewer (Change)
>
> 1000000021 => 1000000021 (None) - this is a Support Group
>
> The Unique combination here will be ";20000;20003;20032;20213;" where the
> two groups with Group-Type "None" has been stripped out.
>
> This is because None-groups should not be able to change access in any
> way, except for row-level-access, but that is calculated in another way.
>
> So depending on if the first User with the unique permission map
> ";20000;20003;20032;20213;" belonged to my STUGUN-group or not, the cached
> file included/excluded permission to thos STUGUN-Active-Links!
>
> SOLUTION: Change the None-Group to View or Change
>
> CONCLUSION: Never map a None-Group to a Role
>
> Please let me know if my deductions seems flawed in any way!
>
> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12
> www.wwrug12.com ARSList: "Where the Answers Are"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
