rob Posted September 3, 2014 Posted September 3, 2014 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.
comment Posted September 3, 2014 Posted September 3, 2014 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. 1
rob Posted September 4, 2014 Author Posted September 4, 2014 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.
comment Posted September 4, 2014 Posted September 4, 2014 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.
rob Posted September 4, 2014 Author Posted September 4, 2014 WOW. A two-in-one. I am off to work on it now. This is great.
rob Posted September 24, 2014 Author Posted September 24, 2014 This works great, Comment, thank you for helping me.
Recommended Posts
This topic is 3712 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now