Here is a script that was distributed by the renown Elliot at the Sage Summit.  Only members that are members of customization group Admin can change the credit limit.  You can adapt to any field 

if oSession.ASObject(oSession.Security).IsMember("admin") <> 1 then
retval = oScript.SetError("Sorry you are not authorized to change the credit limit. Nice try!")
end if

Thanks guys, I just can't see where the variable is for credit limit in that example, if it's there at all - it seems like it isn't and I don't know the syntax or object names to be able to adapt this script.

Or maybe this needs to be added to the salesperson object somehow so it wouldn't need anything else added to it - I've never used scripts in Sage. I'm not sure where I'd begin with this. 

You can manually compile through a button in the lower left of the UDS Maintenance screen.

Click this and it should show a list of event scripts to recompile.

Thanks, getting closer, just seems to block everyone (including admin) from making changes to the SalespersonNo field (it seems that SalespersonNo field was correct as well as the table AR Customer Master). I've tried closing Customer Maintenance, applying the role in User Maintenance and reopening Customer Maintenance, but it won't allow me to change SalespersonNo - the "not authorized prompt is working there" but it blocks even if the user has the role that should be able to make this change. When I added the role to the user account, I tried using All Company as well as the specific company this should affect since that's the one that relates to this customer's file.

The only part I changed in Louie's script was "admin" to "SalesPerson" - I created a role with exactly that name (capital S and P), but that didn't allow me to modify the SalespersonNo when I applied the role to my own account. When I open the SalesPerson role I created in Role Maintenance, I see the role shown as SALESPERSON, so I tried to change the script using all caps and recompile - still not working, unfortunately. I wonder what I'm doing wrong here now. 

I also tried to allow the SALESPERSON role allow permissions (Create, Modify, View, Remove) in Role Maintenance for AR, Maintenance, Customer Maintenance - I only made this change in the Role Maintenance - Tasks tab. Looking in to the options in ODBC Security tab - looks like this alone could possibly control the SalespersonNo from being modified? I'd never looked in this tab before. Doesn't work either, unfortunately - still can't modify salesperson even when given the role set to do so.

The IsMember check may be case sensitive.  Match the case in Role Maintenance to what's in your script, and recompile.

Edit:

ODBC security is only for external query access, nothing functional.

Edit 2:

Change your filter to:

oSession.ASObject(oSession.Security).IsMember("admin") = 0

Hmm, I can't figure it out - I tried deleting the role and recreating it as simply "salesperson" (all lowercase). I modified the script as such and recompiled, applied role to test user - nothing. Tried granting the "salesperson" role all permissions to Customer Maintenance - nothing. 

Can you help me understand the "<>" in the script Louie shared? Should it be either < or > instead? I saw that your script differs in this regard.

<> means "does not equal". 

My understanding is that a successful IsMember match is above zero, not necessarily 1.  Zero definitely means no access.

So if =0 then SetError.

It has been so long I forgot. In checking with Elliott the “admin” in the script is a Role.  Roles are setup in Role Maintenance, and then a user is setup with certain roles. This way with the script you can add another role that is not part of the normal

I use the technique fairly regularly...

I just saw your edit to make this change and it was successful. You guys are brilliant. Thank you so much for your help here. This is going to put a stop to a lot of nonsense - salespeople love to change accounts to their own and it's causing serious problems, as you can imagine. 

I tested in my own account where I applied the "salesperson" role I created and I tested in another account to ensure the block still worked.

Instead of IsMember("admin") I used IsMember("salesperson") - I wanted to control this without needing to use the admin role since some users need access to this, but not everything else in the admin role.

So what I've done is this: 

if oSession.ASObject(oSession.Security).IsMember("salesperson") = 0 then
retval = oScript.SetError("Please contact a supervisor to set or modify salesperson data")
end if

I created a role simply called "salesperson" - all lowercase to try to eliminate issues with case-sensitivity. I removed all the permissions I'd granted to this role and found that the script still worked properly. 

Thanks again everyone - I hope all this information helps others, as well. I'll be able to use this for much more. I just need to learn a bit more about the various functions and become more familiar with the table and field names. This was a bit critical though since it's out of control with how people are messing things up. Cheers

I just saw your edit to make this change and it was successful. You guys are brilliant. Thank you so much for your help here. This is going to put a stop to a lot of nonsense - salespeople love to change accounts to their own and it's causing serious problems, as you can imagine. 

I tested in my own account where I applied the "salesperson" role I created and I tested in another account to ensure the block still worked.

Instead of IsMember("admin") I used IsMember("salesperson") - I wanted to control this without needing to use the admin role since some users need access to this, but not everything else in the admin role.

So what I've done is this: 

if oSession.ASObject(oSession.Security).IsMember("salesperson") = 0 then
retval = oScript.SetError("Please contact a supervisor to set or modify salesperson data")
end if

I created a role simply called "salesperson" - all lowercase to try to eliminate issues with case-sensitivity. I removed all the permissions I'd granted to this role and found that the script still worked properly. 

Thanks again everyone - I hope all this information helps others, as well. I'll be able to use this for much more. I just need to learn a bit more about the various functions and become more familiar with the table and field names. This was a bit critical though since it's out of control with how people are messing things up. Cheers

This is a VERY helpful thread.  Would this also help with limiting permission to change the SalespersonNo in an active Sales Order?  We have an issue with employees changing the Salesperson Number on a Sales Order before it is invoiced.  They do not have access to Customer Maintenance but are able to change the Salesperson Number when processing.  Would the same script work but in a different place/table?  If anyone has any information I would greatly appreciate it.  Thanks in advance!

It should, but if the users can be added into a Customization Group (user maintenance...), creating a customized panel for that group with the SP field disabled / locked might be easier.

Kevin, that is a great idea.  I understand that creating and adding users to the Customization Group is fairly simple.  However, I have not had the experience of creating customized panels yet.  I'll research that and give this solution a try. Thank you!

Add a three letter code to the users' customization group field in User Maintenance.  Then, when using Customizer to create a customized panel, you'll have an option to create one for that group.