Re: Permission problem

2014-08-07 Thread Givens, Gregory CTR NPC, Pers 54
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 
 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: Permission problem

2014-08-07 Thread Charlie Lotridge
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  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 
> 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 be

Re: Permission problem

2014-08-07 Thread LJ LongWing
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 
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

2014-08-07 Thread Charlie Lotridge
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

2014-08-07 Thread Givens, Gregory CTR NPC, Pers 54
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

2014-08-07 Thread Charlie Lotridge
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  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 
> 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

2014-08-07 Thread Charlie Lotridge
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  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 
> 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

2014-08-07 Thread Kemes, Lisa A DLA CTR INFORMATION OPERATIONS
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  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

2014-08-07 Thread Downing, Ryan
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   /cache/

o   /cachetemp/  [might need to check if the folder exists. If it 
does, delete the contents] – Delete files if folder exists.

o   /PluginsCache/

o   /WEB-INF/classes and delete the two files viewstats.dat and 
viewstats.dat.bak

o   /Work/Catalina/localhost/arsys/

o   /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 
mailto: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

2014-08-07 Thread LJ LongWing
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 
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"


Permission problem

2014-08-07 Thread Charlie Lotridge
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: WSDL Permission Problem?

2010-01-13 Thread Lars Christianson
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"


Re: WSDL Permission Problem?

2010-01-13 Thread Jarl Grøneng
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 :
> 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 :
>> **
>>
>> 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
>>
>>
>>
>>  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";>
>>
>>    
>>
>>       
>>
>>          015
>>
>>       
>>
>>    
>>
>> 
>>
>>
>>
>> The return response on Form B
>>
>>
>>
>>  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:Server.userException
>>
>>          ERROR (302): Entry does not exist in
>> database;
>>
>>          
>>
>>             > xmlns:ns1="http://xml.apache.org/axis/";>nc4
>>
>>          
>>
>>       
>>
>>    
>>
>> 
>>
>>
>>
>> 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?

2010-01-12 Thread Joe D'Souza
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 :
> **
>
> 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
>
>
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>   
>
>  015
>
>   
>
>
>
> 
>
>
>
> The return response on Form B
>
>
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>
>
>   
>
>  soapenv:Server.userException
>
>  ERROR (302): Entry does not exist in
> database;
>
>  
>
>  xmlns:ns1="http://xml.apache.org/axis/";>nc4
>
>  
>
>   
>
>
>
> 
>
>
>
> 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?

2010-01-12 Thread Jarl Grøneng
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 :
> **
>
> 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
>
>
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>    
>
>   
>
>  015
>
>   
>
>    
>
> 
>
>
>
> The return response on Form B
>
>
>
> http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>
>    
>
>   
>
>      soapenv:Server.userException
>
>  ERROR (302): Entry does not exist in
> database;
>
>  
>
>      xmlns:ns1="http://xml.apache.org/axis/";>nc4
>
>  
>
>   
>
>    
>
> 
>
>
>
> 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?

2010-01-12 Thread Grooms, Frederick W
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

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   
  
 015
  
   


The return response on Form B

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   
  
 soapenv:Server.userException
 ERROR (302): Entry does not exist in 
database;
 
http://xml.apache.org/axis/";>nc4
 
  
   


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?

2010-01-12 Thread Lars Christianson
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

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 015

  

   



 

The return response on Form B

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 soapenv:Server.userException

 ERROR (302): Entry does not exist in
database;

 

http://xml.apache.org/axis/";>nc4

 

  

   



 

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?

2010-01-12 Thread Grooms, Frederick W
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

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   
  
 015
  
   


The return response on Form B

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   
  
 soapenv:Server.userException
 ERROR (302): Entry does not exist in 
database;
 
http://xml.apache.org/axis/";>nc4
 
  
   


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?

2010-01-12 Thread Joe D'Souza
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



http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 015

  

   





The return response on Form B



http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 soapenv:Server.userException

 ERROR (302): Entry does not exist in
database;

 

http://xml.apache.org/axis/";>nc4

 

  

   





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?

2010-01-12 Thread Lars Christianson
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

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 015

  

   



 

The return response on Form B

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 soapenv:Server.userException

 ERROR (302): Entry does not exist in
database;

 

http://xml.apache.org/axis/";>nc4

 

  

   



 

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?

2010-01-12 Thread Joe D'Souza
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



  http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

 



   015



 

  



  The return response on Form B



  http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

 



   soapenv:Server.userException

   ERROR (302): Entry does not exist in
database;

   

  http://xml.apache.org/axis/";>nc4

   



 

  



  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?

2010-01-12 Thread Lars Christianson
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

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 015

  

   



 

The return response on Form B

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 soapenv:Server.userException

 ERROR (302): Entry does not exist in
database;

 

http://xml.apache.org/axis/";>nc4

 

  

   



 

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?

2010-01-12 Thread Grooms, Frederick W
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

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   
  
 015
  
   


The return response on Form B

http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
   
  
 soapenv:Server.userException
 ERROR (302): Entry does not exist in 
database;
 
http://xml.apache.org/axis/";>nc4
 
  
   


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"


WSDL Permission Problem?

2010-01-12 Thread Lars Christianson
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

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 015

  

   



 

The return response on Form B

 

http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>

   

  

 soapenv:Server.userException

 ERROR (302): Entry does not exist in
database;

 

http://xml.apache.org/axis/";>nc4

 

  

   



 

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

2008-02-12 Thread Ajit Patil
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  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

2008-02-11 Thread Joe D'Souza
{\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 ".\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

2008-02-11 Thread Ajit Patil
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 ".

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

2008-02-11 Thread Joe D'Souza
{\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

2008-02-11 Thread Grooms, Frederick W
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

2008-02-11 Thread Ajit Patil
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"


Re: Permission problem with WebServices

2008-02-10 Thread Joe D'Souza
{\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 with WebServices

2008-02-10 Thread Ajit Patil
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"


Permission Problem

2007-06-27 Thread Rami S Ayoub
**

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"