3 Replies Latest reply on Apr 21, 2014 1:49 PM by padaddy

    Using globals for record level access in hosted environment = problems


      We are going multi-country with our internal solution, hosted on the same server and using the same database, client running full filemaker client. Main table contains about 50k rows and 100 fields. It is a bit slow over WAN but usable and we know we can improve the speed by doing things smarter.


      We wanted to add record level access so users in each country only would see records belonging to their country. The idea was to set a global variable $$HomeCountry at login with the country name of the currently logged in user and then add record level read access like so: $$HomeCountry = OwnerField, where OwnerField contains the name of the country owning the record, set at record creation.


      Access wise this works as planned, when browsing records the user get <no access> where he should get it. But when doing finds using this technique, users get "no records match your find request", even if just using a "*" in the record ID field. I understand in theory filemaker should automagically filter out records a user dont have access to when using finds, but in this case it all breaks.


      We are forced to create a different privelege set for each country, granting read access when OwnerField = "USA", i.e. specifying the condition in clear text rather than using a variable. However now normal finds seems much slower over WAN.


      Not done investigating this but clearly no the smooth ride we had hoped for. Any ideas on what we might be doing wrong or better approaches on handling multi tennant solutions would be greatly appreciated.




        • 1. Re: Using globals for record level access in hosted environment = problems

          I believe the use of $$ in access calculations has changed from v11 to v12, but it is to be avoided (although I wish it worked.) As I recall it was a bit flaky but could not be trusted to work in all cases.


          Add a global field in place of the $$ and set it immediately upon startup. _gHome_Country = OwnerField should be fast enough.


          Edit: Normal finds will be slower, probably similar to your multi-priv set solution.

          1 of 1 people found this helpful
          • 2. Re: Using globals for record level access in hosted environment = problems

            Thanks Scott - I am looking into your approach. To set the gloabl upon startup, I assume the global has to be located in another table as I would not have access to any records in my main table if the global _gHome_Country="" as it would be on startup.


            Any other ideas/approaches out there?

            • 3. Re: Using globals for record level access in hosted environment = problems

              I have a similar situation.  Something I found helpful.  I was using FIND to restrict the visibility of records that the user has no access for (helps avoid confusing people who see the <no access> records).  I used to do this by simply doing a FIND with * in one of the fields (such as an ID field).  This would effectively hide any <no access records>.  But this did not work when using a global as part of the privilege set.  Interestingly what DID work was using an OMIT statement instead.  So rather than FIND * in a field, I would have OMIT with an = in the ID field.  This would effectively omit any records with <no access> giving the same result, except this one of course worked consistently.