6 Replies Latest reply on Nov 21, 2016 8:02 PM by user17152

    Seeking advice on custom permissions


      Hello everyone,


      I've started a (much needed) rewrite of the make-it-up-as-you-go-along Filemaker system I built over the past few years.  One of the first things I plan to tackle is building a custom permissions system and was hoping to solicit some advice and experiences.


      Two types of permissions are needed.  The first are record permissions.  There are many different tables in the solution and we want the ability to control who can Create, View, Edit, and Delete in each of these tables.


      The second type of permission is a single value permission, most likely yes or no, but could be anything really, a number, etc.  For example, my new UI is designed to work across the web, desktop, and iPad Pro.  On the desktop we want certain users to have the ability to "pop" the current window out into a new window.  These "power users" have no trouble managing multiple windows, whereas many of our less sophisticated users do.  So, if the "allow pop out" permission is true, the user sees the Pop Out button.  Otherwise it is hidden.


      A few thoughts so far.  Not all of this is working yet, but this is what I'm thinking...


      I've currently designed the permissions as two tables.  One table is the "Master Permissions" table.  This table is essentially the template for each user.  I can add permissions here as needed during the build out, then have scripts create/update the user permissions.  Each record has a permission name, a variable name, and four permission fields (create, view, edit, delete).  If the permission type is a record permission, all four permission fields are used.  If the permission type is a single value permission, only the first field (create) is used.


      When a user is added to the system, all records from the "Master Permissions" table are copied into the "User Permissions" table and assigned to the new user.  At this point the Admin can adjust/set permissions as needed.


      When the user logs in, permissions are stored as global variables (using the variable name defined in Master Permissions) for the session.  For example, one of my record types is Contacts.  The variable name is $$perm_contact.  When the user logs in, a script loops through all user permissions and sets the variables:


      $$perm_contact_create = 1

      $$perm_contact_view = 1

      $$perm_contact_edit = 0

      $$perm_contact_delete = 0


      Since we have a lot of different record types, a lot of global session variables will be created.  Any thoughts on that?  Another option is storing the permissions in global fields in the "Users" table, but variables seem better to me.


      That's pretty much where I am now in my thinking.  I'd very much appreciate any thoughts and suggestions at this early stage.  Thanks!

        • 1. Re: Seeking advice on custom permissions

          For best security, please do as much of your data access (records, tables, who can create, edit and delete...) via privilege sets in Manage | Security.


          Leave your home grown access control to purely user interface issues such as who can "pop out" a new window and who can't as well as to minimize users from banging their noses on access restrictions set up in Manage | Security.

          • 2. Re: Seeking advice on custom permissions

            I appreciate where you're coming from. So let me ask my question a different way. How do I use the built-in manage security settings to give each user their own access privileges per table?

            • 3. Re: Seeking advice on custom permissions

              You have three different controls in the Security settings. They are User Accounts, Privilege Sets and Extended Privileges.


              You create Privilege Sets which control create/view/edit/delete settings in tables, scripts, layouts and value lists as well as a few other settings. Create as many Privilege sets as you need.


              You then create user accounts for each person. You place each account into one or another Privilege Set.


              Typically, you make privilege sets for different roles. For instance, staff on the shop floor are one set, the shop floor manager will need a different privilege set. The warehouse staff probably look at a different set of tables to sales, so they are a third set, and so on.


              Having made the privilege sets, it is easy to add users. They are sales staff, warehouse staff, sales manager, etc. Their role determines the privilege set that they will need.


              Extended Privileges allow you to extend the behaviour of a Privilege Set by defining a security setting for situations which will span more than one privilege set. Imagine that you had seven privilege sets. You want the users in four groups to be able to generate progress reports. Create a new extended privilege called "Print Reports" and apply it to the four groups. In the scripts that print progress reports you can check the extended privileges for the current user to see whether to go ahead.


              Extended privileges would not be suitable for your pop-up windows example.

              • 4. Re: Seeking advice on custom permissions

                Adding to that,


                External Authentication is an option that makes managing access for large numbers of users easier.


                And you can use Record Level Access control to limit users to only be able to access different groups of records within a given table.

                • 5. Re: Seeking advice on custom permissions

                  To add to the good advice you've already been given, take a look at Extended Privileges. These allow you to create "switches" that you can assign to one or more Privilege Sets, then test using Get ( CurrentExtendedPrivileges )  (FileMaker Pro 15 Help). For example, you can allow [Full Access] and Power User both the ability to pop out a window by assigning them an extended privilege called (for example) "allowPopOut". Then test to see if that value is among the user's Extended Privileges.


                  The reason this is helpful is because it means you don't have to (1) make modifications to all your scripts when a new priv set is to be given a capability, and (2) you don't have to remember to list out all the priv sets; you just call out the Extended Privilege you want.





                  • 6. Re: Seeking advice on custom permissions

                    Thank you all for taking the time to give me your thoughts.  Much appreciated.  The current system uses Privileges as Malcolm explained.  We have a few different privilege sets and currently make no use of Extended Privileges.  I appreciate the little tutorial on Extended Privileges.  I haven't used them and now understand that I should for a variety of different things.


                    I must say, I feel like a bit of a fool as I'd never drilled down into the Privileges dialog box and had not realized that I could set those permissions on a table by table basis for each privilege set.  I wish this was an option for individual users as this is what is required, but I'm sure there will be some overlap so I probably won't have to create a privilege set for each user.


                    When we first started on this project, they didn't want different user types and privilege sets, so we only created a few (Admin, Project Manager, Everyone Else) with basic settings that were applied across the solution.  Over time, as we built it out, I kept getting requests to limit so-and-so's access to such-and-such.  Now that I've decided to tackle a rewrite in the hopes of untangling this rat's nest and finally freeing myself from this project, I knew I needed far more flexible permissions.  Glad I asked the question instead of foolishly trying to reinvent the wheel!


                    And again, thanks for explaining Extended Privileges.  Based on Mike's response, it seems like I should be able to accomplish my other goals by using them.