User Specific Privileges

When was the last time you used FileMaker's Extended Privileges? Never? Well, how about taking advantage of them in such a way that you gain a double level of control over individual user-based privileges.

Using one single privilege set, it's possible to control which specific users can view, edit or delete records from your database. You can also turn off, or on, a specific privilege such as editing an invoice for a whole group of users or one specific user.

It's already hard enough to figure out how to make access privileges specific to users. Implementing this easily within FileMaker's own convoluted security is our ultimate goal.

If setting up security is the last step you take, then watching this video will hopefully reveal how easy it is to set things up at the beginning, or at any time in your solution's evolution.

Since FileMaker Pro provides the Extended Privileges section, there's no reason not to take advantage of it. Let me show you how!

AttachmentSize
UserSpecificPrivileges.zip280.08 KB

Comments

Matt,

Really interesting video. I continually struggle with how to make use of native security when my clients need so much more flexibility and the ability to change stuff without having access to 'Manage Security'. Lots of food for thought in this one, thank you.

Did you consider using ExecuteSQL in the custom function to get the privileges to eliminate the need for the relationship to TO Privileges » Users::privileges

PrivilegeCheck( name ) =

Let ( [
~account = Get(AccountName) ;
~sql = "SELECT " & Quote( "privileges" ) & " FROM " & Quote ( "@Users" ) & " WHERE " &Quote( "accountName" ) & " = ?" ;
~privileges = ExecuteSQL ( ~sql ; "" ; "" ; ~account )
];
not IsEmpty( FilterValues ( FilterValues ( Get ( AccountExtendedPrivileges ) ; ~privileges ) ; name ) )
)

Also, have you given any thought as to how this might work in a multi file solution?

PJ

Each time that ExecuteSQL is called it's the same and running a FileMaker find. This means that each time a record is loaded, especially within list views or portals, the call to the custom function PrivilegeCheck() would be firing off tons of queries.

As a solution grew in size this would become a performance issue.

While it seems easier from a code readability standpoint, it's better to evaluate using the lowest amount of overhead. This will typically come from the context of the user in the solution (I think).

I think this particular implementation would require some performance testing to see if making the query within the custom function would slow things down or not.

Of course, we also have the Evaluate and Get ( LayoutTableName ) functions. These could be used to dynamically evaluate the current context.

There are so many directions you can head with this type of implementation!

-- Matt Petrowsky - ISO FileMaker Magazine Editor