Well....even if this 'fixes' it, you need to address the 'why' eventually...and the only person that can address that is BMC...and being you are running the latest version, latest service pack, latest patch....there would obviously need to be another fix put in place.
On Thu, Aug 7, 2014 at 10:05 AM, Charlie Lotridge <lotri...@mcs-sf.com> wrote: > ** > Greg, I'm also concerned about the problem coming back (I mentioned in > another email I've also seen this happen). Did you ever try manually > clearing the cache directories as LJ & Ryan suggested? > > -charlie > > > On Thu, Aug 7, 2014 at 8:23 AM, Givens, Gregory CTR NPC, Pers 54 < > gregory.givens....@navy.mil> wrote: > >> I've seen this on my system before and it was always with a field with no >> permissions assigned. >> Flushing the cache resolves it sometimes, but I've seen it come back >> after subsequent flushes. >> >> Try assigning an un-used permissions group to the field. >> >> Greg >> >> -----Original Message----- >> From: Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge >> Sent: Thursday, August 07, 2014 10:03 AM >> To: arslist@ARSLIST.ORG >> Subject: Permission problem >> >> ** >> I'm at a loss and would appreciate any suggestions on how to fix this. >> >> >> I have a field on a form that has no privileges configured on it, so no >> one but full admins should see it. But for some reason an underprivileged >> user account can see this field on the mid-tier running on the same >> machine, call it machine QA. I have the same form on a server & mid-tier >> running on machine DEV, and the field is appropriately invisible to the >> (effectively) same user account. >> >> If I point DEV's mid-tier at server QA, the field is appropriately >> invisible. >> >> If I point QA's mid-tier at server DEV, the field is appropriately >> invisible. >> >> I've tried the above on different browsers running on different machines >> with the same results. >> >> So, it seems that the problem manifests ONLY when QA's mid-tier is >> pointing at QA's server. >> >> I've (of course) tried flushing the cache on QA's mid-tier, bouncing QA's >> Tomcat, and even bouncing machine QA itself, but the problem persists. And >> during the these bounces, I've turned off QA's cache persistence but no joy. >> >> The field (in this case) is a display field, so this is NOT an issue >> about seeing or modifying data without appropriate privileges. So I have >> no reason to suspect a problem with ARS itself not enforcing permission >> policies, and in fact the evidence (outlined above) would seem to suggest >> something wrong with QA's mid-tier. But it IS an issue (to me) that the >> field is visible. >> >> I've simplified my description here a bit and the problem does extend >> beyond what I've described here. But my guess is that if I can solve this >> problem the other similar elements will resolve too. Still, if appears >> relevant I can describe more details. >> >> All of the servers and mid-tiers are running v8.1.01 >> >> Has anyone seen this before? Any suggestions on how to fix this? I >> haven't gone as far as uninstalling/reinstalling the mid-tier or tomcat >> yet, do anyone think this will help? >> >> Thanks, >> Charlie >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
