May be stating the obvious but Accounts are assigned with Privilege Sets, and Privilege Sets are configured to enable/disable access to layouts etc., execution of scripts, export...
I quite often do this sort of thing. I tend to have a table called Access that holds user account names and allow you to add new users (not holding password). This is very useful as it can also hold things like email address and other things you want to tie to a user. I then have a handful of scripts that create, active, deativate and delete FileMaker accounts and tie this activity to the layout. I can then use a layout naming convention to determine which layout a user is directed to in a navigation script.
Job List Studio
Job List Sales
Job List Accounts
All show a list of jobs but are tailored to a type of user.
yes, I thought into that direction... Thanks for the inspiration. What else should / could be held in and directed from the Access table?
It depends on the solution really. You could even go so far as to set different level of access for different areas of the system for different people, I've written solutions where there are maybe 4 levels of access (eg read only, user, manager and admin) and multiple areas (eg studio, accounts, sales, despatch etc). You might want to set Bob to have user access to Studio and Despatch, view Sales and no access to Accounts. Sylvia might have user access to accounts but nothing else, whereas Tim has Manager access to everything.
I tend to fire a script on file launch that grabs your access into global variables and this is then used to direct you within the navigation. The only problem with this is that it doesn't help if somebodies access is changes during the day, so you need to keep triggering a script to gather their access or get it through a relationship.
As I say, I generally use it for naavigation but you can use it for anything you need to really.
The closer you stay to the FM security implementation the safer your solution will be. One of the often overlooked features in a privilege set is the use of "Extended Privileges" that you can define yourself for fine-grained control.
Think of a privilege set as a "role"; each role that you can define in your solution should correspond to one privilege set.
Storing security settings as data is not terribly secure.