Does the global field (to be accessible during searching) have to be in the same table? Global tables references should work anywhere, if it was acceptable to separate the data fields from the global ones.
I recently read somewhere they were using slide panels to toggle between editable fields and non-editable based on whether the user was supposed to be in Edit mode. Thought I bookmarked it but cannot find it. Best I could find quick on google was: FileMaker Pro 13: Slip Sliding Away - The Scarpetta Group, Inc. (but that's not the exact one). Another thread had a little hint about the technique: Popover and Slide-control Love
If only the global field is set to editable in Browse on the "Default" view, and you can quickly slide over to an identical "Edit" view (possibly after checking permissions further) - it might get you what you want.
I can't get your issue, editing global field don't need record.
If, in the privilege set, the layout is set so that records through that layout are view-only, then no fields can be modified, global or otherwise.
My issue is that I would like to let the user modify the global field without letting the user modify any other records. I want to prevent modification to anything except the global field.
Oh, I see. I tested with predefined view-only privilege. Your issue is using layout access, not record access.
Don't you use record access? There is per field setting for edit/view/no access.
I think easiest workaround is that use a script showing dialog with run as full access option. But not seeing good.
If I set per-field access, it affects those fields on all layouts, so the user can't edit those fields anywhere. Moreover, my goal is to simply prevent adding or deleting records.
Create a ReadOnly priv set. Then go to Data Access & Design/ Records, select Custom Privs and then the table. Go with Limited Field Access and set the global(s) to modifiable. (This probably deserves a place on the Unintuitive List, but it's also handy for things like relogin scripts etc.)
I'm doing my best to understand the dilemma you describe, and failing to do so.
I would think that using the following settings would allow for your intentions to be realized:
In the example "foo" table shown above, a user can view records; they can edit data in records, i.e. access fields, but they will not be allowed to create or delete records in the table. This will be true regardless of layout.
If there is another layout where you do wish to allow the user to create/delete records, then I might consider using a custom menu to add restrictions to a specific layout, but my first choice would be to use the above if the restriction is to apply across all layouts.
Apologies if I totally missed the point here -- hoping that I have not, and that this might be of help.
I want the user to edit/create/delete records from a given table in some layouts but not others, while being able to edit a global field from that table in all layouts.
I suppose I'll have to pursue the custom menus approach.
Perhaps use a method like the one used in FileMaker Developer Cup challenge 3, where a global variable is set in a script triggered by OnLayoutEnter and set according to a Case statement, and then permission levels are assigned based on the global variable setting. That way any time that layout is accessed in a "normal" way (ie, not going into layout mode, moving to the desired layout, then going back to browse mode) they'll be assigned a permission level that doesn't allow creation or deletion of records. There are ways to work around it if the user is malignant, but it should stop the casual user from accidentally deleting records. The calculations for when a user can modify a field could become very convoluted.
I must say, tho, that I prefer the idea of setting up a table with only one field, the editable global field, and letting all permission levels edit it.
Is this a security requirement or a user management issue? Since users can have different rights depending on the layout, I assume it's the latter.
If so, just take away the ability to delete a record using a custom menu. Set the "Delete..." menu item's "Install when" option to a calculation to hide it on some layouts.
I like to use a textbox (not a field, just text) with a value of "1" on a hidden part of the layout (usually an off-layout popover with its hidden status = 1). I name it "prevent.delete" and in the Install when calc box= If ( GetLayoutObjectAttribute ( "prevent.delete" ; "content" ) ; 0 ; 1 ). That allows delete by default. You can play around with that if you want to prevent delete by default.