We are receiving error while while posting EDI orders from TN webmanager. We are getting “You are not having authorization to view this” after submitting the doc. Servers are working fine and did restart also after changing the config file tn.webmgr.46config=true .We are using http://localhost:5555/invoke/wm.tn/receive service. Its having TN Partner ACL.
Also on TN webManager console some fields on left panel are disappeared and its showing user as default ,inspite of logging using our own LDAP id.
Please help me out on this…
You should try changing tn:receive service Execute ACL to Anonymous or Default and give it a shot.
Was this working before?
Thnx for the reply.
But when I am changing it its stating - [ISS.0081.9002] Cannot perform operation without Write ACL privileges on wm.tn:receive.
Also the user who are using it are added in group which are having TN Partner ACL.
One more thing I didn’t get that why some config disappears on left side of TN Webmanager.
It is due to permissions/ACL issue for that user.So grant that user in the group of TNAdministrators ACL also…
You got error when changing Execute ACL?
We are seeing here some strange behavior with staging TNwebmanager, dev/prod working fine as usual so perhaps Fixes doestn’t seems to be a problem.
If we are using below options then its showing all config items and we are able to submit EDI docs also.
1) Firefox: If we are using Firefox browser then after login click on Refresh Button. It will load all the config items defined for user.
2) Internet Explorer : On IE with SP3 installed it works fine also with refresh after login.
Look like some browser caching issue.
But dont the root cause for this.
Its weird.Could be browser issue as you mentioned…Is this a critical roadblock for you?
Thanks for reply.
Actually not a block as for now , we told client to use firefox. But we have to come up with the RCA for this. Its working fine in Dev/Prod.
In contact with webMethod support but they are also bowled out with this.
They are suggesting some webManager fixes but they are also not sure abt this.
Do you have the same issue when you login as local user with sufficient privileges, rather than using an ldap login id?
We have a similar issue, when logging in as an ldap user.