Scripting

Unrelated table requires access in Role maintenance to run script The Customer has written a script using UDT to look at the User Code and the Salesman Code to permit access to only the Salesperson's customers. For example, if the user logged in is HSW and the Salesman Code is 0001, the UDT would have an entry of HSW0001. Upon opening the Customer in Customer Inquiry if the combination of Login and Salesperson matched, the screen would open; if not, a message says you are not authorized. And it works perfectly, IF a totally unrelated table is allowed in Role maintenance. So we removed the table; the result, the script no longer worked at all. By trial and error, we found a totally different UDT that required access. Upon checking (allowing) it, the script now works again. Can anyone offer an explaination as to why allowing access in Role maintence to a UDT that has nothing to do with the script being currently run, would affect the script?

Are you saying the user must have access to ALL UDTs or the script does not work, or is it just this extra one?

It was just the one UDT. So to eliminate the problem, we deleted that one. Mysteriously, now we have to grant access to a different UDT.

Sounds like one of the RoleKey values in Sy_RoleSecurity is not matched up properly to the Task key in Sy_Task - IOW role security could be messed up. Now it is true the only reason a UDT even shows up in Role Maintenance to begin with is it was added to the menu so that you can Maintain UDT. Here is a thought - what if you deleted the UDT again, and add it back again but this time don't ""Add UDT to Desktop"". This way it will never appear in Role Maintenance to begin with and you shouldn't be subject to Role Security when you reference it in your script. When you do want to Maintain UDT, you do so directly from UDF Maintenance from the Custom Office / Main menu (and no doubt client has already secured access to that).

Well, it seems very logical but unfortunately that didn't resolve the issue. We deleted the UDT referenced in the script and re-added it (AR_UDT_SALES_ACCESS). This time, we did not add it to the Desktop. However, the problem persists. But, it makes sense that something is off as it pertains to role security. Remember, the UDT that was incorrectly required by the script was an old UDT that I already deleted (AR CORETYPE). After I deleted it, the UDT that my script required changed to this new one (AR_UDT_SALES_TERRITORY). So, I'm worried if delete this new UDT that the script will just jump to another UDT. Is there a way to look in the Sy_Task and Sy-RoleSecurity to see what is off? and if so, what would I look for?