"Is there any way to check a user's access to a database that is not the current one?"
Define ustored calculationfields in the other file that return account information.
Get (accountname) would return the account name used to open the file. Get (privilegesetname) would do the same for the privelege set name.
Now your script can check these fields to find that information.
Okay, I can see how that might work, but I am not seeing how I would build the calculation field in the other file, as I may have as many as four permission levels to the file. How would I set up the calculation field to hold the 4 [Get(privilegeSetNames)]'s?
Don't you want just the privilege set name of the current user?
If client 1 logs on with account/password xyz/AAA, the field shows the privilege set name for this account.
If another client logs on with account/password xxx/BBB, the field returns a different value on their computer.
Isn't this what you need to disable buttons that lead to <access denied> areas, functions?
Not sure, but I figure this would also need an "Open File" in the startup script of your Menu File so that the field was available to check. This could be hidden and fairly seamless as long as the username and password were the same for both Menu File and the functional Dbases.
Just thinkin out loud...
I am using External authentication, which means I control access via groups in Active Directory. I have different privilegesets for every major file. The reason why is because the permission requirements are so granular.
Example: I have a "Quoters" privilege set. Quoters have the same access to certain databases. However, only one Quoter has Write access to the Job database (So only one can create new jobs)
I also have an A/R privilege set. A/R people have the same access to certain databases. However, one of the A/R people has Write access to the Job database (So one of the A/R can create new jobs)
I can either create groups at the user level in Active Directory (a group for almost every second person-messy), or I can put a user in multiple groups to suit the user's role (much cleaner). So a user will be authenticated as FMUser in the Main Menu database, Quoter in the Quotes database, and JobCreator in the Jobs database. It works very well and good, I was just wondering if there was some way to get a user's permissions for another file and as I write this I see that the fact that authentication is handled by Actve Directory, there may be no way to use script-level commands to query Active Directory to find out if a user is part of a group that has rights to a different file... rats...
I figured out a way to do it (very granular access control). This method gives you an "Active Directory" feel to External Authentication groups, i.e., to give access to a Filemaker resource, simply add a user to a group in Active Directory. This method is only necessary when you implement complex permissions and have users that have multiple roles in a company.
To set up permissions on a button that takes you to a resource:
1. Write a script for the button that opens a new database file (I'll call it XYZ). Have it open Hidden. (You have to open the file or permissions won't work)
2. Set up a group in Active Directory that matches your needs (e.g. Management Report)
3. Create the new database file XYZ.
4. Set up permissions on the file thus:
- the first group is the Active Directory (AD) group to whom you want to give access (e.g. Management Reports)
- underneath that group, create a group that contains all Filemaker Users (you need to set this up in AD as well). This allows you to show users a proper custom message if they don't have access.
5. Write a script that checks for the group. If they are a member of the group, then runs a second script in the first database file that points to the resource. Then close the XYZ file. If authentication fails, give the user a messagebox informing thus, and close the XYZ file.
Once the first file is done, it's easy to copy the file to create others. This will be overkill for most of you, but it's great for me. Now whenever a role changes or gets added, I do all of the work in Active Directory, instead of editing scripts, database file permissions, etc.