10 Replies Latest reply on Mar 15, 2016 7:10 AM by dtcgnet

    Complex Access Restriction Question


      OK, so I'm going to try to explain this as best I can in the hope that it's clear (a) what's currently happening and (b) what I have been asked to do to update the logic.

      The application I support has three levels of access:

      • User
      • Office Admin
      • Sys Admin

      The restrictions to the data are as follows:

      • Sys Admin: can see/access everything;
      • Office Admin: can see all data for records who have the same location set as the user, ie London Office Admin can view all records with London as Office location;
      • User: can see all data for records where they are a team member ie each record has a list of users (team) assigned to it, so if the user is in a team, then they can view the record.

      Whilst there are privilege sets and extended privileges for the three user groups, the list of records shown to the user on the initial screen is handled by a script:

      The variables are populated during a start-up script as follows:


      So, this all works as expected, and the users only see the data applicable to their access level.

      Now comes the change. They want User & Office Admin users to be able to the same list of records as Sys Admin, ie all records, BUT only be able to access the data based on the same logic above, ie users only access records they are a member of and office admin only access records assigned to their office location.

      Currently, access to a underlying data for each record is via a button, which runs a GoTo Layout script step to view the underlying data for the selected record in the appropriate layout:


      So what I need to do is hide the button for records the user should not have access to, but based on the above, am in the dark as to how to convert the Find logic to allow me to hide or display a button control.

      Is this enough detail? If not, please ask for more info and I will provide what I can. And if I don't respond straight away, it's because I'm out of the office after today until 1st March, so please don't think I'm ignoring your help/questions.

      Many thanks


        • 1. Re: Complex Access Restriction Question

          In the inspector you can set a calc for when to not show the button. The return needs to be boolean but the calc can be complex and account for evaluating the current $$ values of the user and office with the ones that are associated with the record.


          i am sure you will have some AND and OR in there.

          • 2. Re: Complex Access Restriction Question

            in order to simplify things, I would


            - define a summary calc, List Of, clientPrimaryKey


            - the initial script that does the finds ends by setting a $$AllowedClients var to ¶ &  that List Of & ¶


            - the button is hidden when the client ID is not a member of $$AllowedClients

               ==> not Patterncount($$AllowedClients; ¶ & clientPrimaryKey & ¶)

            • 3. Re: Complex Access Restriction Question

              Thanks @bigtom.

              OK, but can that calculation perform a record requests and find as the current script does? That's my confusion here - I understand how a script works, and how a boolean calculation works, but I just don't know enough about FileMaker to work this change in. My plan is to give it a go myself, and if it doesn't work, then defer back to the third party developer who wrote the system...but I would love to get it working myself!

              Thanks again


              • 4. Re: Complex Access Restriction Question

                Thanks as well @siplus.

                So thinking further, where would the summary calc reside - within the logic for the hide button code?

                Could I create a custom function or script that I can call from the hide code that returns a boolean?

                Thanks again


                • 5. Re: Complex Access Restriction Question

                  the summary calc must be defined in the table that it summarizes, i.e. Clients. That's where you're doing your initial searches, too.


                  You don't want it to be part of the button's hide logic because you don't want a unstored calc to be evaluated all the time in order to determine the visibility of a button. I already gave you the button's hide formula.

                  • 6. Re: Complex Access Restriction Question

                    Many thanks @siplus. I will have a look at this and come back when (not if!) I have more questions.



                    • 7. Re: Complex Access Restriction Question

                      You indicate that you have three privilege sets set up in the security for this solution. Do you have record level access defined for those privilege sets? It sounds like not.


                      Go into the Office Admin privilege set in Security. You can customize the "View" portion for each data table. Click a table, and in the View column, enter a formula such as $$OfficeID = Tablewithrecords::OfficeField. From then on, your Office Admin users would see only the records which correspond to their office. (That's an example).


                      From what you've said, you want Office Admins to be able to VIEW all records. For the Office Admin set, then leave View set to "Yes". For the EDIT field, you'd enter a formula like the one I showed, because when you say "access", I think you mean "have edit rights to".


                      By the way...if you use FM's built-in security in this way, the "Find" portion of your startup script wouldn't really be necessary. FM would automatically know which records to show each person in each privilege set.

                      custom record.tiff

                      • 8. Re: Complex Access Restriction Question

                        Also, if your privilege sets are set up this way, FM will know the Record Access level for each record. You can then use that to show or hide the button.


                        Button Formula: Hide when Get ( RecordAccess ) ≠ 2


                        That would hide the button for any record which the user did NOT have View AND Edit privileges.


                        Read up on it at:


                        • 9. Re: Complex Access Restriction Question

                          Thank you for your in-depth explanation - it's very useful. The overall security was set up as part of the initial system (by a third party who developed the bulk of the system) and whilst there does appear to be security groups present, am not sure they work in the same way as your explanation.

                          Since the initial post, the logic has changed, and we have taken a different track - two identical layouts, one with a button to list all schemes and all users to view each record's team members, and the original (unchanged) layout that is restricted to only the records the user's access allows. In practice, this isn't working either as a user, whilst he can see the buttons to view team members, the pop-over doesn't work, which I can only assume is because of the way the security/privilege sets have been set up. The third party developers are due back in to help with the items I can't tackle, so will need to discuss with them how to modify the current security. I am fully aware that the logic to allow a User to view all is against what was initially requested, which is always frustrating to developers to change this kind of logic so late in the day.

                          So looking at the privileges, I've figured out how the system restricts access - in the screen showing 'Custom Record Privileges', the records for 'CLIENT' are set to limited, and the following calculation is used to restrict access:

                          PatternCount ( a_ks_Associate_ID_Team ; $$UserID )

                          The global variable $$UserID is stored as part of a start-up script and the value is the user's log-in/network ID. So this is why a User cannot see the records for all teams. I suspect, seeing as how the layouts are set up, I could remove this restriction, but don't know enough about how this may affect other restrictions/security.

                          Thanks again for your help, I will work with the third party to resolve this as am not knowledgeable enough in the complexities of FM to figure it out.



                          • 10. Re: Complex Access Restriction Question

                            That formula is saying, "There's a field in the CLIENT table called a_ks_Associate_ID_Team. If, in a CLIENT record, one or more patterns in that field are the same as $$UserID, then the user can see the record."


                            Your developer can listen to your needs and modify that formula pretty easily, or add similar formulas to other privilege sets. For instance, if "$$OfficeID" is set when a user logs in, then the formula in the Office Admin table could be:


                            PatternCount ( a_ks_Associate_ID_Team ; $$UserID ) Or PatternCount ( TheOfficeLocationField ; $$OfficeID )


                            That would allow a person with Office Admin privileges to see records directly assigned to him/her AND also any record from the same office as the Admin.