If logged in under a privilege set without rights to modify a field in another table, I want to run a script which can modify that field.  I thought that I could check 'run with full access' in the script but that does not work because when looking in debugger the field displays 'no access' and the script will not change the field. 

 

Do I need to re login as full access developer before I can set that field?  I think I am unclear on the purpose or meaning of that checkbox 'run with full access' and I searched and can not find anything on it.  Can someone explain a bit more for me?  Thank you for listening.

Could you provide a practical example? If your script is defined, for example, to:

Set Field [ YourTable::RestrictedField; YourTable::RestrictedField + 1 ]

then running the script with full access privileges will increment the field by 1 - even if the field is set to 'no access' for the current user's privilege set.

 

That doesn't mean that the current user running the script will see the change; in fact, they will see nothing but <<No Access>. But the value in the field will be modified.

Then that was my mistake.  I saw the <no access> and thought it was not working because of it but it was not working because of different mistake of mine.  I am just now learning security and beginning to put it in and it seems strange to deny a person access and then provide them a button which does just that.  So is it normal to include a test in the script that, at the moment of running, must be true in order to bypass security?  Is that how it is used?  Would it not be easier to put that 'test to bypass security' in the calculation box in privilege set?

 

I am not clear when to use script with 'full access' checked although I know it is best to let privileges handle critical things but is not everything in that category?  Thank you very much for responding, Comment.  

I don't know if I can list any general rules, but I happen to have a very handy example for you:

 

Suppose you need to populate a global field with the current user's account name, as part of the startup script. The global field is of course out of bounds to any user, so this action must be performed by a (sub) script that is set to run with full access privileges.

WOW.  A two-in-one.  I am off to work on it now.  This is great.

This works great, Comment, thank you for helping me.