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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Permission problem
Charlie, Have you shut down Tomcat, deleted all of the contents of the 'cache' directory for Mid-Tier, and restarted?...this is moderately different than a 'Flush Cache' from the config console. On Thu, Aug 7, 2014 at 9:02 AM, Charlie Lotridge lotri...@mcs-sf.com wrote: ** 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
Re: Permission problem
To further the idea of a manual flush….please try the following steps: Manually clearing the midtier cache · Shutdown the tomcat service. · Delete the contents of the following folders: o Midtier/cache/ o Midtier/cachetemp/ [might need to check if the folder exists. If it does, delete the contents] – Delete files if folder exists. o Midtier/PluginsCache/ o Midtier/WEB-INF/classes and delete the two files viewstats.dat and viewstats.dat.bak o Tomcat/Work/Catalina/localhost/arsys/ o Tomcat/temp/ · Restart tomcat service · Check if preload checkbox is checked in the midtier config o If yes, preload will automatically commence. o If no, enable preload, and then click “Flush cache” to trigger preload. (Note Click on Flush Cache only once.) Preload progress can be monitored in midtier logs – INFO level logging. Hope this helps ☺ Regards, Ryan. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, August 07, 2014 11:07 AM To: arslist@ARSLIST.ORG Subject: Re: Permission problem ** Charlie, Have you shut down Tomcat, deleted all of the contents of the 'cache' directory for Mid-Tier, and restarted?...this is moderately different than a 'Flush Cache' from the config console. On Thu, Aug 7, 2014 at 9:02 AM, Charlie Lotridge lotri...@mcs-sf.commailto:lotri...@mcs-sf.com wrote: ** 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_ _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
Re: Permission problem
Make sure when you are flushing your local Browser cache (in IE) that the Preserve Favorites website data is UNCHECKED and that Form Data is CHECKED. Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, August 07, 2014 11:07 AM To: arslist@ARSLIST.ORG Subject: Re: Permission problem ** Charlie, Have you shut down Tomcat, deleted all of the contents of the 'cache' directory for Mid-Tier, and restarted?...this is moderately different than a 'Flush Cache' from the config console. On Thu, Aug 7, 2014 at 9:02 AM, Charlie Lotridge lotri...@mcs-sf.com wrote: ** 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_ _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
Re: Permission problem
Ok! Yes, that seems to have solved the problem. I kind of thought that the cache persistence option was about keeping or not keeping the contents of that directory, so didn't bother trying it. What I didn't add earlier is that changes to the user account's permissions (but not including adding Administrator) did resolve the problem, but only for short periods of time. It would then come back after a while. I'm crossing my fingers that this solution will persist. Thanks LJ! -charlie On Thu, Aug 7, 2014 at 8:06 AM, LJ LongWing lj.longw...@gmail.com wrote: ** Charlie, Have you shut down Tomcat, deleted all of the contents of the 'cache' directory for Mid-Tier, and restarted?...this is moderately different than a 'Flush Cache' from the config console. On Thu, Aug 7, 2014 at 9:02 AM, Charlie Lotridge lotri...@mcs-sf.com wrote: ** 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_ _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
Re: Permission problem
Thanks for these additional suggestions. Lisa, yes, I did uncheck that option (but it didn't help). Ryan, so far I've only deleted the cache directory. If the problem re-manifests I'll try your more extensive approach. -charlie On Thu, Aug 7, 2014 at 8:12 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS lisa.kemes@dla.mil wrote: Make sure when you are flushing your local Browser cache (in IE) that the Preserve Favorites website data is UNCHECKED and that Form Data is CHECKED. Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Thursday, August 07, 2014 11:07 AM To: arslist@ARSLIST.ORG Subject: Re: Permission problem ** Charlie, Have you shut down Tomcat, deleted all of the contents of the 'cache' directory for Mid-Tier, and restarted?...this is moderately different than a 'Flush Cache' from the config console. On Thu, Aug 7, 2014 at 9:02 AM, Charlie Lotridge lotri...@mcs-sf.com wrote: ** 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_ _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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Permission problem
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
Re: Permission problem
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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Permission problem
Welleven 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 patchthere 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
Re: Permission problem
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: ** Welleven 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 patchthere 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
Re: Permission problem
Charlie, I had not tried clearing the tomcat cache I created a group called Remedy Admin and assigned the permissions (assigning it to Administrator did not work) At the time we were on 7.5 and I only noticed it on buttons and tab panels. I have not seen the issue since updating to 7.6.04 Greg -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Thursday, August 07, 2014 11:05 AM To: arslist@ARSLIST.ORG Subject: Re: Permission problem ** 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 smime.p7s Description: S/MIME cryptographic signature
Re: WSDL Permission Problem?
But still the permissions are done on the server level, so when changing permission on a field and/or form you does not need to recache mid-tier. (at least not for the SOAP part, you got this error: ERROR (332): You do not have write access (at create time) to field..) On mid-tier you may see the field, but you does not see the value. Regards, Jarl 2010/1/13 Joe D'Souza jdso...@shyle.net: Yes you do need to clear the cache. This is because the form definition is held by the Mid-Tier server and a new definition is created whenever there is a change in the forms definition. The Mid-Tier server has no way of knowing something has changed on the ARS server level. Filters (and off course escalations) are the only objects that reside only on the AR Server and hence do not need a Mid-Tier server re-cache when changed. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Jarl Grøneng Sent: Tuesday, January 12, 2010 4:14 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? If you need to flush a cache manually if you change permission, then it is something wrong with the security model. The permission level has to be done on the server layer. In earlier version of AR Server row level access was omited if you access the server using soap. Regards, Jarl 2010/1/12 Grooms, Frederick W frederick.w.gro...@xo.com: ** Also … Don’t forget… If you change the permissions you need to clear the web server cache (That has bit me a couple of times in the past). Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 1:52 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Fred Joe, I can’t test the permissions changes on the other forms until tomorrow. As for your questions, “Are your sub form pushes from Filters or child data inside the XML?” – Filters “Is VT:VirtualTechnicianForm the form that the entry is being created by the WSDL? Does this form has the right permissions to 1 and 112?” – VT is the form, yes. Thanks again for your help. I’ll let you know success or failure tomorrow. -L From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I’m running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on “Assignee Group” Field 112, but this field is included in both forms and is visible to “Public”. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
I added the permissions to the underlying form. No joy. The only common point I can find now is the two forms (that will not give back a newly created ticket number) also send emails on ticket creation. I'm hesitant to dig around inside the AREmail forms, changing permissions. Since I can get the ticket by resubmitting key fields in a GET, I'm moving forward in spite of this error. Thanks again for all your help. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Tuesday, January 12, 2010 2:48 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? Also ... Don't forget... If you change the permissions you need to clear the web server cache (That has bit me a couple of times in the past). Fred _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
WSDL Permission Problem?
Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
What are the permissions on your Entry_ID (Request ID) field on Form B? Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Fred, Permissions for Request ID on both forms: Assignee Public Submitter -L From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Tuesday, January 12, 2010 11:18 AM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? What are the permissions on your Entry_ID (Request ID) field on Form B? Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Lars, What version of ARS are you on? Since you have already eliminated the permissions to Field 1 and Field 112 I'd like you to check the following.. Do you get the same error from the user tool? If so, AND if you are below ARS 7.5, check your Status History table (H table in the database) to have a corresponding entry for that record. If the corresponding record in the H table is missing, you can get that error below ARS 7.5. ARS 7.5 is the first version since I have known ARS that does not require the Status History table to be populated. Anything below and if the H table has its corresponding missing contents, you will get that error. Hope this helps... Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 12:40 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Fred, Permissions for Request ID on both forms: Assignee Public Submitter -L -- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Tuesday, January 12, 2010 11:18 AM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? What are the permissions on your Entry_ID (Request ID) field on Form B? Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Joe, * ARS 7.1 Solaris 10 * Mid-Tier 7.1 Solaris 10 The user tool doesn't exhibit this error. Even with the SOAP error, the ticket is created inside Remedy properly. Instead of the ticket number being returned in the SOAP response, I get that error message. I checked the H table for that form, and it is being populated with the proper entry ID. I've turned on logging for both the arapi and arsql. There are no errors in the SQL processing. There is an error in the API which tells me what I already know: */+XMLCE ARXMLCreateEntry from Webservice (protocol 13) at IP address 172.25.7.23 /* Tue Jan 12 2010 11:27:25.6947 */ARXMLCreateEntry -- schema VT:VirtualTechnicianForm from Webservice (protocol 13) at IP address 172.25.7.23 /* Tue Jan 12 2010 11:27:25.7866 */-XMLCEFAIL It's as if the SOAP response is being returned before the ticket is finished being created. I do have a theory. This form pushes information into other forms. Would I need Field 1 and 112 access on those other forms as well as the main form that interacts with the XML service? Thanks again for giving me further areas to look into. -Lars From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Tuesday, January 12, 2010 11:52 AM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? Lars, What version of ARS are you on? Since you have already eliminated the permissions to Field 1 and Field 112 I'd like you to check the following.. Do you get the same error from the user tool? If so, AND if you are below ARS 7.5, check your Status History table (H table in the database) to have a corresponding entry for that record. If the corresponding record in the H table is missing, you can get that error below ARS 7.5. ARS 7.5 is the first version since I have known ARS that does not require the Status History table to be populated. Anything below and if the H table has its corresponding missing contents, you will get that error. Hope this helps... Cheers Joe From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Is VT:VirtualTechnicianForm the form that the entry is being created by the WSDL? Does this form has the right permissions to 1 and 112? Do try permitting the forms that information is being pushed to as well just in case your workflow references some information from them before or while creating that record. Worth a try. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 1:43 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Joe, a.. ARS 7.1 Solaris 10 b.. Mid-Tier 7.1 Solaris 10 The user tool doesn't exhibit this error. Even with the SOAP error, the ticket is created inside Remedy properly. Instead of the ticket number being returned in the SOAP response, I get that error message. I checked the H table for that form, and it is being populated with the proper entry ID. I've turned on logging for both the arapi and arsql. There are no errors in the SQL processing. There is an error in the API which tells me what I already know: */+XMLCE ARXMLCreateEntry from Webservice (protocol 13) at IP address 172.25.7.23 /* Tue Jan 12 2010 11:27:25.6947 */ARXMLCreateEntry -- schema VT:VirtualTechnicianForm from Webservice (protocol 13) at IP address 172.25.7.23 /* Tue Jan 12 2010 11:27:25.7866 */-XMLCEFAIL It's as if the SOAP response is being returned before the ticket is finished being created. I do have a theory. This form pushes information into other forms. Would I need Field 1 and 112 access on those other forms as well as the main form that interacts with the XML service? Thanks again for giving me further areas to look into. -Lars -- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Tuesday, January 12, 2010 11:52 AM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? Lars, What version of ARS are you on? Since you have already eliminated the permissions to Field 1 and Field 112 I'd like you to check the following.. Do you get the same error from the user tool? If so, AND if you are below ARS 7.5, check your Status History table (H table in the database) to have a corresponding entry for that record. If the corresponding record in the H table is missing, you can get that error below ARS 7.5. ARS 7.5 is the first version since I have known ARS that does not require the Status History table to be populated. Anything below and if the H table has its corresponding missing contents, you will get that error. Hope this helps... Cheers Joe From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Turn on your filter logging as well as workflow logging in the web server logs section. Are your sub form pushes from Filters or child data inside the XML? Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 12:43 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Joe, * ARS 7.1 Solaris 10 * Mid-Tier 7.1 Solaris 10 The user tool doesn't exhibit this error. Even with the SOAP error, the ticket is created inside Remedy properly. Instead of the ticket number being returned in the SOAP response, I get that error message. I checked the H table for that form, and it is being populated with the proper entry ID. I've turned on logging for both the arapi and arsql. There are no errors in the SQL processing. There is an error in the API which tells me what I already know: */+XMLCE ARXMLCreateEntry from Webservice (protocol 13) at IP address 172.25.7.23 /* Tue Jan 12 2010 11:27:25.6947 */ARXMLCreateEntry -- schema VT:VirtualTechnicianForm from Webservice (protocol 13) at IP address 172.25.7.23 /* Tue Jan 12 2010 11:27:25.7866 */-XMLCEFAIL It's as if the SOAP response is being returned before the ticket is finished being created. I do have a theory. This form pushes information into other forms. Would I need Field 1 and 112 access on those other forms as well as the main form that interacts with the XML service? Thanks again for giving me further areas to look into. -Lars From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Tuesday, January 12, 2010 11:52 AM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? Lars, What version of ARS are you on? Since you have already eliminated the permissions to Field 1 and Field 112 I'd like you to check the following.. Do you get the same error from the user tool? If so, AND if you are below ARS 7.5, check your Status History table (H table in the database) to have a corresponding entry for that record. If the corresponding record in the H table is missing, you can get that error below ARS 7.5. ARS 7.5 is the first version since I have known ARS that does not require the Status History table to be populated. Anything below and if the H table has its corresponding missing contents, you will get that error. Hope this helps... Cheers Joe From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Fred Joe, I can't test the permissions changes on the other forms until tomorrow. As for your questions, Are your sub form pushes from Filters or child data inside the XML? - Filters Is VT:VirtualTechnicianForm the form that the entry is being created by the WSDL? Does this form has the right permissions to 1 and 112? - VT is the form, yes. Thanks again for your help. I'll let you know success or failure tomorrow. -L From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Also ... Don't forget... If you change the permissions you need to clear the web server cache (That has bit me a couple of times in the past). Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 1:52 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Fred Joe, I can't test the permissions changes on the other forms until tomorrow. As for your questions, Are your sub form pushes from Filters or child data inside the XML? - Filters Is VT:VirtualTechnicianForm the form that the entry is being created by the WSDL? Does this form has the right permissions to 1 and 112? - VT is the form, yes. Thanks again for your help. I'll let you know success or failure tomorrow. -L From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I'm running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on Assignee Group Field 112, but this field is included in both forms and is visible to Public. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
If you need to flush a cache manually if you change permission, then it is something wrong with the security model. The permission level has to be done on the server layer. In earlier version of AR Server row level access was omited if you access the server using soap. Regards, Jarl 2010/1/12 Grooms, Frederick W frederick.w.gro...@xo.com: ** Also … Don’t forget… If you change the permissions you need to clear the web server cache (That has bit me a couple of times in the past). Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 1:52 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Fred Joe, I can’t test the permissions changes on the other forms until tomorrow. As for your questions, “Are your sub form pushes from Filters or child data inside the XML?” – Filters “Is VT:VirtualTechnicianForm the form that the entry is being created by the WSDL? Does this form has the right permissions to 1 and 112?” – VT is the form, yes. Thanks again for your help. I’ll let you know success or failure tomorrow. -L From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I’m running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on “Assignee Group” Field 112, but this field is included in both forms and is visible to “Public”. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: Where the Answers Are_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: WSDL Permission Problem?
Yes you do need to clear the cache. This is because the form definition is held by the Mid-Tier server and a new definition is created whenever there is a change in the forms definition. The Mid-Tier server has no way of knowing something has changed on the ARS server level. Filters (and off course escalations) are the only objects that reside only on the AR Server and hence do not need a Mid-Tier server re-cache when changed. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Jarl Grøneng Sent: Tuesday, January 12, 2010 4:14 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? If you need to flush a cache manually if you change permission, then it is something wrong with the security model. The permission level has to be done on the server layer. In earlier version of AR Server row level access was omited if you access the server using soap. Regards, Jarl 2010/1/12 Grooms, Frederick W frederick.w.gro...@xo.com: ** Also … Don’t forget… If you change the permissions you need to clear the web server cache (That has bit me a couple of times in the past). Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 1:52 PM To: arslist@ARSLIST.ORG Subject: Re: WSDL Permission Problem? ** Fred Joe, I can’t test the permissions changes on the other forms until tomorrow. As for your questions, “Are your sub form pushes from Filters or child data inside the XML?” – Filters “Is VT:VirtualTechnicianForm the form that the entry is being created by the WSDL? Does this form has the right permissions to 1 and 112?” – VT is the form, yes. Thanks again for your help. I’ll let you know success or failure tomorrow. -L From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lars Christianson Sent: Tuesday, January 12, 2010 10:53 AM To: arslist@ARSLIST.ORG Subject: WSDL Permission Problem? ** Hi folks, I have a question for you. I’m running ARServer 7.1, Mid-Tier 7.1; both Solaris 10. When I create a new ticket in two different forms using SOAP, I get a ticket number back for the first form but not for the second form. In both cases, a ticket is created inside Remedy. For example: The return response on Form A soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns0:OpCreateResponse xmlns:ns0=urn:Test_TestWSDL ns0:Request_ID015/ns0:Request_ID /ns0:OpCreateResponse /soapenv:Body /soapenv:Envelope The return response on Form B soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringERROR (302): Entry does not exist in database;/faultstring detail ns1:hostname xmlns:ns1=http://xml.apache.org/axis/;nc4/ns1:hostname /detail /soapenv:Fault /soapenv:Body /soapenv:Envelope I thought this issue was related to row-level permissions based on “Assignee Group” Field 112, but this field is included in both forms and is visible to “Public”. Has anyone else come across this issue before? Any advice would be welcome. Thanks in advance, -Lars ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: Where the Answers Are
Re: Permission problem with WebServices
Hello Joe, I've taken care of all the things...but still it is not working... Now I m creating one Java client let's see what happens... Thanks n Regards, Ajit Joe D'Souza wrote: Ajit, Have you got Allow any user to Submit ticked in the Permissions tab of the field property? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Ajit Patil Sent: Tuesday, February 12, 2008 1:56 AM To: arslist@ARSLIST.ORG Subject: Re: Permission problem with WebServices Hello, I am working on the single form, no other form is using this data. It gives the error when creating new request through SOAP UI. It says something like You do not have permission to this field Field ID. But when I see the permissions for that field they are public... I am using ARS 7.0.1, MS-SQL. Is there any problem with SOAP-UI? Thanks... Ajit Patil wrote: Hello All, I've created a webservice... It works fine when used with Filter...But it gives permission error when using with any other consumer like SOAPUI... I've given public permission to the WebService but still it gives the same error... Anyone has the idea about this Thanks in advance ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are -- View this message in context: http://www.nabble.com/Permission-problem-with-WebServices-tp15405819p15429297.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Permission problem with WebServices
{\rtf1\ansi\ansicpg1250\deff0\deftab360{\fonttbl{\f0\froman\fprq2\fcharset0 Times New Roman;}{\f1\fswiss\fcharset0 Arial;}}
\viewkind4\uc1\pard\lang1033\f0\fs20 And by underlying form I do not mean just the core data form but any other form that data is being pushed to on the creation or modification of that record. You haven't specifically stated if its the modify or create operation that is bombing out so assuming that it is either or both, I would check all other supporting form of that main form that data is being written to, to make sure the user has sufficient rights during that modify or create action..\par
\par
Cheers\par
\par
Joe\par
\par
-Original Message-\par
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Grooms, Frederick W\par
Sent: Monday, February 11, 2008 9:27 AM\par
To: [EMAIL PROTECTED]
Subject: Re: Permission problem with WebServices\par
\par
\par
What permissions error is it giving? \par
\par
-Original Message-\par
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ajit Patil\par
Sent: Monday, February 11, 2008 3:00 AM\par
To: [EMAIL PROTECTED]
Subject: Re: Permission problem with WebServices\par
\par
Hello Joe,\par
\par
The underlying form and the fileds have appropriate permissions, so that the user using webservice can submit the values. \par
\par
But still it is giving the same error...\par
\par
Thanks...\par
\par
Joe D'Souza wrote:\par
\par
Ajit,\par
\par
What about permissions to the underlying data forms that the data gets\par
\par
stored in?\par
\par
Do all the fields that are used in the web service have permissions \par
for the user that the web server uses to submit?\par
\par
Joe\par
\par
-Original Message-\par
From: Action Request System discussion list(ARSList) \par
[mailto:[EMAIL PROTECTED] Behalf Of Ajit Patil\par
Sent: Monday, February 11, 2008 12:33 AM\par
To: [EMAIL PROTECTED]
Subject: Permission problem with WebServices\par
\par
\par
Hello All,\par
\par
I've created a webservice...\par
\par
It works fine when used with Filter...But it gives permission error \par
when using with any other consumer like SOAPUI...\par
\par
I've given public permission to the WebService but still it gives the \par
same error...\par
\par
Anyone has the idea about this\par
\par
Thanks in advance\par
\pard\plain\f1\fs20 {\pard\plain\f0\fs18 \line No virus found in this outgoing message.\line Checked by AVG Free Edition. \line Version: 7.5.516 / Virus Database: 269.20.2/1271 - Release Date: 2/11/2008 8:16 AM\line }\par
}
Re: Permission problem with WebServices
What permissions error is it giving? -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ajit Patil Sent: Monday, February 11, 2008 3:00 AM To: arslist@ARSLIST.ORG Subject: Re: Permission problem with WebServices Hello Joe, The underlying form and the fileds have appropriate permissions, so that the user using webservice can submit the values. But still it is giving the same error... Thanks... Joe D'Souza wrote: Ajit, What about permissions to the underlying data forms that the data gets stored in? Do all the fields that are used in the web service have permissions for the user that the web server uses to submit? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Ajit Patil Sent: Monday, February 11, 2008 12:33 AM To: arslist@ARSLIST.ORG Subject: Permission problem with WebServices Hello All, I've created a webservice... It works fine when used with Filter...But it gives permission error when using with any other consumer like SOAPUI... I've given public permission to the WebService but still it gives the same error... Anyone has the idea about this Thanks in advance ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Permission problem with WebServices
Hello, I am working on the single form, no other form is using this data. It gives the error when creating new request through SOAP UI. It says something like You do not have permission to this field Field ID. But when I see the permissions for that field they are public... I am using ARS 7.0.1, MS-SQL. Is there any problem with SOAP-UI? Thanks... Ajit Patil wrote: Hello All, I've created a webservice... It works fine when used with Filter...But it gives permission error when using with any other consumer like SOAPUI... I've given public permission to the WebService but still it gives the same error... Anyone has the idea about this Thanks in advance -- View this message in context: http://www.nabble.com/Permission-problem-with-WebServices-tp15405819p15426946.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Permission problem with WebServices
{\rtf1\ansi\ansicpg1250\deff0\deftab360{\fonttbl{\f0\froman\fprq2\fcharset0 Times New Roman;}{\f1\fswiss\fcharset0 Arial;}}
\viewkind4\uc1\pard\lang1033\f0\fs20 Ajit,\par
\par
Have you got Allow any user to Submit ticked in the Permissions tab of the field property?\par
\par
Joe\par
\par
-Original Message-\par
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Ajit Patil\par
Sent: Tuesday, February 12, 2008 1:56 AM\par
To: [EMAIL PROTECTED]
Subject: Re: Permission problem with WebServices\par
\par
\par
Hello,\par
\par
I am working on the single form, no other form is using this data. \par
It gives the error when creating new request through SOAP UI.\par
\par
It says something like You do not have permission to this field Field\par
ID.\par
\par
But when I see the permissions for that field they are public...\par
\par
I am using ARS 7.0.1, MS-SQL.\par
\par
Is there any problem with SOAP-UI?\par
\par
Thanks...\par
\par
Ajit Patil wrote:\par
\par
Hello All,\par
\par
I've created a webservice...\par
\par
It works fine when used with Filter...But it gives permission error when\par
using with any other consumer like SOAPUI...\par
\par
I've given public permission to the WebService but still it gives the same\par
error...\par
\par
Anyone has the idea about this\par
\par
Thanks in advance\fs18 \f1\fs20\par
}
Re: Permission problem with WebServices
Hello Joe, The underlying form and the fileds have appropriate permissions, so that the user using webservice can submit the values. But still it is giving the same error... Thanks... Joe D'Souza wrote: Ajit, What about permissions to the underlying data forms that the data gets stored in? Do all the fields that are used in the web service have permissions for the user that the web server uses to submit? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Ajit Patil Sent: Monday, February 11, 2008 12:33 AM To: arslist@ARSLIST.ORG Subject: Permission problem with WebServices Hello All, I've created a webservice... It works fine when used with Filter...But it gives permission error when using with any other consumer like SOAPUI... I've given public permission to the WebService but still it gives the same error... Anyone has the idea about this Thanks in advance No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.2/1270 - Release Date: 2/10/2008 12:21 PM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are -- View this message in context: http://www.nabble.com/Permission-problem-with-WebServices-tp15405819p15407583.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Permission problem with WebServices
Hello All, I've created a webservice... It works fine when used with Filter...But it gives permission error when using with any other consumer like SOAPUI... I've given public permission to the WebService but still it gives the same error... Anyone has the idea about this Thanks in advance -- View this message in context: http://www.nabble.com/Permission-problem-with-WebServices-tp15405819p15405819.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Permission problem with WebServices
{\rtf1\ansi\ansicpg1250\deff0\deftab360{\fonttbl{\f0\froman\fprq2\fcharset0 Times New Roman;}{\f1\fswiss\fcharset0 Arial;}}
\viewkind4\uc1\pard\lang1033\f0\fs20 Ajit,\par
\par
What about permissions to the underlying data forms that the data gets stored in?\par
\par
Do all the fields that are used in the web service have permissions for the user that the web server uses to submit?\par
\par
Joe\par
\par
-Original Message-\par
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Ajit Patil\par
Sent: Monday, February 11, 2008 12:33 AM\par
To: [EMAIL PROTECTED]
Subject: Permission problem with WebServices\par
\par
\par
Hello All,\par
\par
I've created a webservice...\par
\par
It works fine when used with Filter...But it gives permission error when\par
using with any other consumer like SOAPUI...\par
\par
I've given public permission to the WebService but still it gives the same\par
error...\par
\par
Anyone has the idea about this\par
\par
Thanks in advance\par
\pard\plain\f1\fs20 {\pard\plain\f0\fs18 \line No virus found in this outgoing message.\line Checked by AVG Free Edition. \line Version: 7.5.516 / Virus Database: 269.20.2/1270 - Release Date: 2/10/2008 12:21 PM\line }\par
}
Permission Problem
** I have given permission for the support in the Incident consol Incident User with Fixed licenses - but I got error when they need to change the status any ideas Regards, Ramy ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
