Have you tried simply not giving users access to the global field(s) in question? If the purpose of the field is functional why do they need to even know that the field exists?
Hi, do you mean on any layouts etc?
I do not have it on user layouts but all our work goes through security testing so not having a field on a layout does not mean they cannot alter it – but I do not think this is what you are suggesting anyway…
do you mean change that field access for that field userid to “View Only” (for that priv set) and that would be ok as the script that is running to set the global is set to use full access rights anyway so it does not need the user to have modifiable access?
In which case I have not tried that and will test and see if that would solve the issue instead!
Thank you for taking the time to reply ☺
Can't reproduce this. I know that in the past I've removed access, at the table level in security settings, from global fields (usually because I forgot that I really did want the limited user to be able to change the global field). I just double-checked in FM15, and if I create a priv set that can't edit the table with the global in it, or if I grant access but specifically mark the global field as view only using the "field access" option, then I can't edit the global field under that priv set, with the field on the layout and open in browse.
What specifically are you seeing that makes you think A) the global field is not accessible under the privilege set and B) they can edit it anyway?
Not sure this is relevant to your issue, but I did discover some time ago that record privileges are evaluated when a record is opened, and don't get reevaluated as each edit is made. Is it possible that your user opened the record when allow edit equaled 1, then unset it and reset it without committing? That would be allowed...