You might set up this structure:
Set up an entry control file where an MSR reader or fingerprint scanner identifies the user. Then create additional files with one file for each privilege set you've defined in the actual database file. Define one account name and password in each of these "opener" files that matches to an account name and password defined in your main database file. Set File Options on each of these files so that each opens itself with this account name and password automatically when the file is opened. Define a script in each of these files that opens your main database file. You can use Open File or Perform Script [//select script in file to be opened] to open the file. Each opener file can be exact copies of each other except for the account names and passwords.
This system works like this. A script in the entry control file identifies the user and their privilege set. It then performs a script in the appropriate opener file which in turn opens your database file with the same account name and password as defined in the opener file to select the appropriate security settings.
If you need to pass the name of the person identified by the entry control file, you can look up that name in a table in the entry control file and pass it along to each subsequent file as a script parameter.
Security Note: Put all the opener files on the server (not a local machine) and set up sharing so that they are not listed in the Open Remote dialogs.
thanks for the advice. I'm going to test it out, probably going to run into some trouble and come back...
I have another question related to this issue of an opener file. Is there a way to prevent users from using anything else on the computer. i.e. I don't want any user to be able to open any program on the computer. How can I make Filemaker act as the sole operating system of the computer unless otherwise opted out by a script?
That last question is more an issue of what permissions you set on that computer's user accounts. If you bring up the access control file in FileMaker on a computer with a user account that denies access to those functions, you're pretty close to what you want. If you then use FileMaker Advanced to set the file to run in Kiosk mode, I think you can then lock up a machine the way you want.
I'm working with the entry control file.
When I use a perform script to open the main database file, a new window opens up, does it always have to be that way? How does this play into the entry control file?
The script should be able to hide the window. Your entry control file can even use a script that uses Open File [hidden] to open these "opener" files during start up.
I haven't put the open file in the start up.
However I'm not sure there will be a difference.
When I trigger either the open file [hidden] or the perform script [on main file], a window opens up, starts running the main file start up script, and then either stays there (open file) or performs the script I'm triggering. But that window stays open.
Is there a way to have the opener be a kiosk solution and have the main run as kiosk when it is being opened in kiosk mode?
the reason is, I would like to be able to control the kiosk solution as a by user/computer and not just by admin-nonadmin.
I was thinking in terms of using Open Hidden with the opener files, not the main file as you need it to open when the access control process completes. It would need to be visible then wouldn't it? Otherwise, I'm missing something here.
Kiosk Mode is an option set on the file as I understand it. You'd need two different files to have one that opens in Kiosk and one the opens normally. If you use a data separation model, this might be fairly easy to do. A data separation model would separate your main file into two files--a data file with all the tables and an interface file with all the layouts and scripts. You could have two interface files--one kiosk and one not Kiosk that both link to the same data file. The kiosk file can be an exact duplicate of the "normal" file so you can easily generate new copies of it each time you update the "normal" file.
You really got me thinking outside the box I've been in for the last couple of months. You have some really solid ideas.
After going over your last response, I came up with a possible highest efficency solution. I would really like your opinion.
A little background:
My solution, when finalized, will cover pretty much every aspect of a multi-unit business. From Sales, to inventory, to administration, cash flow and materials resource planning, with a lot of complex dynamic reports.
It is used at multiple locations, many of which are in areas where high speed internet isn't really high speed. As of now there are two files, one which is my main file (on FMS11), to which all users connect and another file that holds attachment files (jpgs, .doc, etc) so the size of my main file doesn't explode.
What I think might help things out a great deal:
Use the data separation model. Have the main files with data in them on the server and build a separate file to implement on as a client on end user's computers. This client file, hosted on each users computer, would have all layouts and scripts built in, so there is no unnecessary information being transmitted over the internet, just hard data. As suggested by you, every time an update for the client version is finalized, there could be two subversions of it: one to run normally and one to run in kiosk mode.
Taking this a step further, I've recently had some experience with SQL and it seems many times faster than filemaker to produce complex reports that summarize a great deal of data. So I'm thinking of having the database be MYSQL and just build the client with Filemaker.
What do you think?