And hold my breath until it that fix comes out? :) I put in a ticket a couple years back now about how an import of an XML definition file containing a form with more than 90 (or ninety something, I forget now) fields would fail. It got logged as a bug and I'm still anxiously waiting for that fix to show up in a release!
Alright, maybe not so anxiously as I've long since worked around the problem. And since it would appear that this issue isn't affecting many people, it would understandable not be a priority to BMC. This problem would probably rate the same as my XML import problem. But what I'm really hoping that your suggested fix has eliminated the problem from my system (whereas perhaps my previous attempts flushing the cache or changing permissions only masked it temporarily somehow). I'm also hoping that since the problem isn't affecting many people, this means that whatever caused the problem in the first place is a corner case and is unlikely to happen to me again. On Thu, Aug 7, 2014 at 9:07 AM, LJ LongWing <lj.longw...@gmail.com> wrote: > ** > 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_ >> > > _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"
