I'm sure I'm not the only one to have this complaint. I design and develop a solution with full-access (admin) and I create new accounts that have limited permissions.

Is there any way (other than closing the file and reopening it under the user account) to test permissions while still logged into the database as admin (full access)? Is there a 3rd-party plug-in or any ware that allows this?

Thanks,

GSG

There is a Re-login script step in the Accounts section. It works (just tried it). You'd have to run it in each file.

I've been building routines to create, modify and delete Accounts from a central file that stores staff members (it calls scripts in the other files). A bit of work at first, but It beats heck out of doing it manually for 10+ people, each with their own password.

Minor complaint: You can no longer import scripts between files with same-named fields and expect them to line up. Every field name is prefixed with its table name; so unless you rename the tables to be the same, you have to reset all the fields. I see why, but it sure handicaps the ease of swapping scripts. I think I'll rename the table next time and see how that works -)

Fenton,

Have you been able to get your login system to propogate password changes and new accounts to other files? If so, can you share how this is done?

FMP 7 includes several script steps that deal with Accounts. They're all pretty self explanatory.

Take a look at a Security demo that I posted in March, I think it's in the FMP 7 Samples forum (or something similar). It uses many of the script steps to manage user accounts.

Thanks Vaughan,

Not quite what I'm looking for, but I appreciate your input. I'll move my question to the Security forum. Hopefully someone will have dealt with this issue.

Well, it calls a script in the other file. The key is that both the Account name and the password (if you should so wish) can be taken from fields, just like any other piece of FileMaker data. They are not a weenie hard-coded text value.

So, in the central "Reps" file (sales reps mostly), I have the fields: AccountName, PW (password), Privileges (Privilege Set name).

I'm just using the person's name as the Account name. Let me say right here that it's not the most secure system in the world. You may want to use something else; in fact the beauty of the system is that the administrative users can change any of this and propagate the changes; I'm just getting it started. The regular users have no access to the layout or fields. Any suggestions for greater security welcome.

I set the current Account name into a global field. I call a script in another file (let's say "Names").

It gets the Account name, into a local global (could also access directly; I'm not fully optimized in v.7 thinking yet).

Commit Records (no dialog).

There's a relationship back to Reps based on global _gAccountName.

If [ Reps_gAccountName::Privileges = "User" ]

RepNames.zip

"What there is NOT is any way to see what Accounts exist..."

Security I assume.

With the sample security file I posted earlier, it all works well as long as all user account work is done through the fabricated interface that uses scripts. If a root users with full access starts changing accounts there is no way for the fabricated interface to work out what's going on.

Ender -- though the sample file is simple it has all the basics for propagating the user names and passwords across multiple files. It's all done with scripts.

Thanks everyone for the responses. Found the script steps. Works perfectly; I hid a button on my layout that switches users and references the master password typed into a global field. Sweet!

Oops. In my Names file the Loop runs Go To Record/Request [Exit, "Next"]. That's just plain dumb -)

It should have an Exit when it runs out of words instead. So much for importing scripts in a hurry.

RepNames.zip

Now what we really need is a way to use debug while "spoofing" a login.