How to keep Layout from Showing up in List?

I would like to log user accesses so the currently logged in user needs access to that layout. But, I don't want that layout to show up in the layouts menu. That "manage...layouts" seems to be global so even when logged in as 'admin', if I've unchecked the box to show that layout, I still can't see it.

How do you allow a user to (in a script) access a layout so the script can add a record, but the user himself cannot see that layout in the layout menu?


Also today, when doing some work, the FMS 20 worker machine stopped working and I got 503 errors. I had to manually log into FMS and re-enable the worker machine. Anyone else get this problem occasionally?


Many solutions use an approach where the layout used by the script is a dedicated "utility" layout that is not revealed in the list of layouts visible in the layout menu. Such layouts are often blank form view layouts, and they just serve the function of allowing a script to go do some work in a particular context, and nothing more.

I could see the above approach possibly working in the scenario described above. If the script is allowed to access the utility layout to do its work, that should remove the need for the user to have permissions to see the layout that you don't want them to see in the layout menu. And yet, removing such permissions for that particular privilege set would not have any bearing on what you could see as a Full Access user.


Thanks Steve! :slight_smile:

1 Like

In my systems/solutions I use several "utility" layouts which are just a blank form view layout as @steve_ssh has described. Mine are labeled like: Sys_InvLineItems, Sys_Invoices, Sys_LocationHistory, etc., where the "Sys" part lets me know immediately at a glance that it's a blank layout for System use only. Use of this type of layout for running scripts is often much more performant such that no fields means less overhead when the layout window is opened. I open my utility layouts off-screen -4000pts typically (as a floating document window), so the user doesn't see it in the event of a network quirk.

What struck me in your post was that your users have access to the File... Manage... menu, so I'm assuming the user(s) in this case has some development responsibilities. In my solutions, users are presented custom menus which exclude the Manage... menu item, as well as restrictions against layout modifications (or delete records, etc.) in Security. (The custom menus also lack View... Layout Mode, Records... New Record, Delete Records.. etc.) Perhaps you have some options available in these areas to add to your control.

Appreciate your posting.

This really wasn't a "solution" per se, just a quick data entry form to gather some data.

Understood, Oliver. I just wanted to see if we were missing something. I enjoy the conversation. :slightly_smiling_face:

1 Like

Thanks....One question though...I created a custom menu but the "Tools" menu still shows up. Tried to "hide", etc., but can't get Tools to go away when the user is logged in.

I'm changing the menu to the user menu on Get(AccountName)="". There's only one user so that method seems to work OK.

How do I remove the Tools menu?


It's my understanding that if, under Preferences, Use Advanced Tools is checked, the Tools menu will be displayed regardless of custom menu items. But without Full Access Privileges the tools aren't available without authorizing as a Full Access user. For example if one wants to run the Script Debugger on a staff member's computer without access to the tools found in the Tools menu you'll be asked to authenticate.

Turning off the "Use Advanced Tools" seems like it's an "applies to all" for all FileMaker apps. Definitely not what I want (though it does turn off the Tools menu...).

With Use Advanced Tools enabled, the Tools....Script Debugger still seemed to work for a non a full access user. The Data Viewer did ask for authentication.

Still don't see how to get rid of Tools menu for non admin user.

Script Debugger still seemed to work for a non a full access user.

Interesting. In my experience, I’ve had to authenticate to use the Script Debugger for “staff” sessions. I’m on Mac and using v19 mostly. I’ve not tested it lately, but will look at it again.

Perhaps it’s because in Security all users only have privileges to execute scripts. Or some other difference in out setup/environment.

I just checked, @OliverBarrett , and while the Debugger does open work window, once you call a script full access authentication is required. The UI is slightly different from the Data Viewer in that there’s no message on the Debugger window.

Yep, thanks. The only real solution is to somehow get the Tools menu off of what the user sees.

Thank you.

In over 18 years of FM development and a couple hundred production FM solutions deployed, I have NEVER allowed a user access to the menus, or toolbar. Not ever (OK, a limited toolbar in Preview mode, but that is the only exception :slight_smile: .

If the table you wish to write data to, is related, you can place fields off-screen right (invisible in non-layout mode), and with create through relationship turned on, directly write to those fields from with a script on that layout.

If the table you wish to write data to, is NOT related, then you can open a new window, even positioned off screen ( left -5000, top -5000 - an "off-screen" window), write the data and close the window. NOTE that when debugging that script, off-screen windows do NOT show up off-screen)