What's the easiest way to disable fields for some users?
I have a variable which gets set when a user logs in which sets $$Permissions to whatever they're allowed to do (add users, edit users, add tasks, edit tasks, etc.).
The permissions aren't linear, so, for example one teacher can edit courses, and another can enter cases, but most teachers can't do either, and admins can do anything. I could in theory have a few dozen "Privilege groups" and manually set which fields each one can use, but that would be a nightmare, so I want to do it on a script.
I tried adding a script trigger OnObjectEnter to deselect the field (go to object "logo") but it doesn't seem to happen until AFTER the pulldown gets changed, which sort of defeats the point.
One thing I've done in the past is turn the fields into buttons and add a script where I pass in a variable saying "go to this object if you have positions". Is there a cleaner way?
I tried adding a script trigger OnObjectEnter to deselect the field (go to object "logo") but it doesn't seem to happen until AFTER the pulldown gets changed
I'm struggling to reconcile these two. One is about buttons and the other is about a field.
OnObjectEnter should fire as soon as a field is entered. But you might want to try an OnObjectSave/OnObjectModify trigger on the field you wish to protect.
The only surefire way to prevent edits by the wrong users is via a privilege set though.
I also like your idea of using a button or global field instead of the dropdown and then scripting the record modification so the script can confirm their privilege.
You can create a permission set which has flexible conditions.
You will have to set up a way to provide extra permissions to teachers. These extra permissions get stored in a global field, either as json, or just as a list of unique strings, when they login.
Then your permission set for a editing a table could be:
You can use the visibility settings (inspector) to make an object only visible for some groups (roles or 'Privilege groups' in file/define/security (or similar, no english system here) or any other criteria
We strongly recommend native FM accounts what means that You have 'roles' instead of any kind of the so-called 'Ersatz-Method' where for example FM fields describe the options for different users - but using the 'Ersatz-method' in some way can also be helpful.
Sometimes, we have native FM accounts but create some entries in some fields by login according to the specific role
We have solutions where different user (-groups) have different objects on a layout, done by visibility settings - a single layout might have a quite different look from the users perspective..
Thanks @Markus but with 9 different privileges there are 512, so just using "roles" won't work.
I usually do the visibility method you describe, where I have two copies of the field, one that's editable and one that's not and I hide the editable one from people who don't have permission, I was just hoping for a more elegant solution.
Another option is to put the special fields into a different file or table. Let the file or table have unique security settings, such as, having most users be in a read-only permissions.
That's a good idea. They keep rethinking who has access to what and I can't see pulling out 20 fields and reprogramming all the SQL and layouts and scripts, but definitely something I'll keep in mind for the future.
This is actually an awesome idea.... next time I'll do better.
The hugely powerful but highly obscure security model can do this easily. You can restrict field view/edit/delete conditions based on anything you can write a calculation for. Dig down in your privilege set to custom access and you can quickly get overwhelmed by the immense granularity in what can be controlled for access.
On the negative side, these changes are obscure; wondering why something that should work, doesn’t, because you forgot or were unaware of a security restriction imposed, is often confounding, especially well after the action.
Side note: if you have a field with set up in the security model (say an employee pay rate only visible to that employee) hiding it is a trick; FM evaluates that field as “?” so a hide on that field for the question mark content removes the glaring eyesore.
Yes it is often both easier and less obscure to use a button bar segment with a label of the actual field and a popover with the field in it for editing. Then you have script control of who can access the popover AND the button press can fire a match field for a value list selection.
