FileMaker 5.5 added some cool new features, most notably record-level security, and it was FileMaker 3, I believe, that gave us Status(currentgroups), to an aging...no, ANCIENT security architecture that otherwise dates back to at LEAST FileMaker Pro 1.0, possibly even earlier. Record-level security is nifty and at least potentially delightful, but the overall effect is sort of like adding Ethernet to a Mac SE. Even the available plug-ins just don't cut it, although I'm not going to discuss them here.


FILEMAKER SECURITY (AS IT IS NOW)
a) The security system was obviously not designed with ongoing multi-user usage in mind (it possibly dates so far back into the mists of time that the product for which it was designed didn't even support networking)! To even so much as see what the existing passwords are, and what privileges are associated with them, requires unserving the solution and opening it as host.

b) Programmers duplicate fields and layouts all the time. When we so so, the security privileges (the ones that we can't see on the live networked solutions we're working on) are duplicated with them with no warning or cues.

c) Security is file-level rather than solution-level, meaning that the structure of permissions must be set separately for each file. Short of taking screen shots or jotting down notes in BBEdit or the back of your lunch napkin, you can't reference what the settings were in one file while you're tinkering with another.

d) The point of entry that identifies the user is the password, which can only be created by someone with full access to the file, meaning that only the programmer can add or remove passwords from the solution even if FileMaker 5.6, let's say, suddenly supported editing passwords on served solutions the way Filemaker 5.0v3 and later support editing Field Defs. In practice, that means that each password represents a set or permissions and access privileges, rather than each password representing an individual who HAS permissions and access privileges. (This is doubly true for shrink-wrapped and other solutions that are deployed in places other than the workplace of the programmer).

e) The interface for setting up security is the armpit of FileMaker, a program otherwise blessed with intuitive user-friendly interfaces. Each password is created with a set of basic file-wide permissions, then groups are created, after which passwords are associated with groups, for which layout-specific and field-specific and mode-specific (well, edit vs read-only which amounts to the same) privileges can be set, each group being defined, functionally, as the use of the password (since users enter a password), yet each password can belong to more than one group? The first few times I tried using the Overview screen, I had to bring up the Help menu and drag out the manual. Heck, my head hurts just from thinking about it. This has got to be the most unintuitive and user-hostile arrangements to ever appear in FileMaker. (Oh, that password also goes with this other group that has these completely different privileges??)

f) FileMaker cheerfully accepts ridiculous security setups without so much as a warning dialog, allowing you to create a group that has read-only access to all layouts but editing privileges on dozens of fields, or vice versa, or editing privs on various combos of fields and layouts for groups defined by/as passwords that, as passwords, don't allow field editing at all. Neither the Overview screen nor the Password screen give you a clear sense of what the user of a given password is or is not able to do.

g) Menu control drops from "All Menus" to "Editing Only" in one ugly step, so that removing the ability to Delete All Records or Replace via menu command means stripping out the ability to Find or Sort, etc., unless you restore them all via script. Kiss Command-F goodbye.

(written in the FileMaker 5.5 era)