5 Replies Latest reply on Aug 22, 2013 4:17 PM by philmodjunk

    Find returns records with <no access>

    djwait

      Summary

      Find returns records with

      Product

      FileMaker Pro

      Version

      12.0v4

      Operating system version

      Windows 7 Pro 64 bit

      Description of the issue

      User with restricted view permissions performs a find; filemaker returns records with (which are the records that the user should not have access to)

      Steps to reproduce the problem

      - setup file with several records
      - allow at least two users; one with full access, one with restricted view & edit to some subset of the records
      - check that restricted view & edit work (that is, a "show all" will return records with )
      - with restricted user access, perform a find with a wildcard (or really, any valid find request) and see that records still show up

      Expected result

      Expect a Find to not return records that user does not have view access

      Actual result

      Find requests executed with a restricted user permissions still return records with

      Exact text of any error message(s) that appear

      None

      Configuration information

      I am trying to make it so that the restricted access user does not see the records, by performing a scripted Find when the user accesses the file. Interestingly, it seems like the Find re-sorts the records (though it still returns records with )

      Attached image, top to bottom; a table view of the test file, first will the full access user logged in. Then a table view of the restricted access user logged in (restricted to CIR_v3::Last_Change_Name = "djwait"), then the same view after I run the login script for the restricted access user (which performs a Find, CIR_v3::Edit_Status; "*").

      Script steps:

      Enter Find Mode [ ]
      Set Field [ CIR_v3::Edit_Status ; "*" ]
      Perform Find [ ]

      screen_shots.JPG

        • 1. Re: Find returns records with <no access>
          philmodjunk

               If you then perform a find with the * operator on this layout manually, do you also get that result?

          • 2. Re: Find returns records with <no access>
            djwait

                 Hi PhilModJunk,

                 Interestingly, no (and I'd not tested that until you mentioned it, thanks, it's a good test); I had to open up the menu permissions on my restricted "CS user" (I'd set "Available Menu Commands" to "Minimum"), but with full menu commands and status bar available to that user, I logged in as my test restricted access CS user and performed a wildcard find from the status bar (click "Find" then type just * into the field) on the same field (CIR_v3::Edit_Status) on the layout; the find returned just the one record that user has view & edit access to. 

                 Still logged in as my test restricted access user, I then clicked "Show All" in the status bar (as expected, all three records appear, two with <no access> as expected) then I run the login script from the status bar and get all three records again.

                 FWIW, here's the lines of the login script again:

                 #Test for CS User
                 If [ PatternCount ( Get(AccountPrivilegeSetName);"CS User" )>0 ]
                 Go to Layout [ “CIR_v3” ]
                 Enter Find Mode [ ]
                 Set Field [ CIR_v3::Edit_Status ; "*" ]
                 Perform Find [ ]
                      Else If [ PatternCount ( Get(AccountPrivilegeSetName);"CA User")>0]
                       
                 (end script snippet)
                  
                 From there I have other users that I test for in a similar manner (that's the "CA User"). I've checked that above snippet by putting in an "open URL" step after the "Perform Find" and before the "Else If", then logging in as that CS User and seeing the URL pop up; so I know Filemaker is running that set of code within the If statement for the CS User.
                  
                 So, I'm stumped. Is there a place I can post the file for folks to poke at?

                  

            • 3. Re: Find returns records with <no access>
              philmodjunk

                   You can upload files to a sharing site such as Drop Box and then post the download link here.

                   Since your tests have already confirmed that the script is being performed, the next possibility is that the script is tripping a script trigger that does a show all records or something similar to undo the very find just performed by your script.

                   If you have FileMaker Advanced, launch the database without opening the file and enable the script debugger, then use the File menu to open the file so that you can step through your start up script in the debugger. This way you can watch and see if another script performed by a trigger pops up and interferes with your results.

                   If you don't have advanced, I'd put in a Show Custom Dialog step just after the Perform FInd[] step to confirm that the start up script is performing the right section of this code and that it is producing the correct results at that point in the process.

              • 4. Re: Find returns records with <no access>
                djwait

                     Short answer; the login/start up script was set to "Run script with full access privileges" 

                     Long answer; thanks for the suggestion on the Show Custom Dialog. I ended up putting these two debugging steps like this after every step in my script:

                     Set Variable [ $one; Value:Get(LastError) ]
                     Show Custom Dialog [ Title: "Test"; Message: $one; Default Button: “OK”, Commit: “Yes”; Button 2: “Cancel”, Commit: “No” ]
                      
                     I incremented the $<number> variable by hand as I wrote the script; brute force and ugly, but it functional. I could see that the script was executing each step as I expected.
                      
                     Somewhere in there I started thinking about user access, and remembered I'd copied my login/start up script from another script that runs with full access privileges. I unchecked that box for the login script, and it now does what I expect (that is; a Find executed by a user with access to a subset of records returns only the records they have access to, without any <no access> records found). I suppose it's another one of those "don't be a lazy coder" lessons learned.
                      
                     Maybe it's a side issue; it sounds stupid to say so, buy I'd not have expected "Run script with full access privileges" to be so "full access." There's this line in Filemaker 12 help:
                      
                     "Use Run script with full access privileges to enable a script to run with the full access privilege set, even if the current user has logged in with a privilege set that does not have full access. Using this feature enables users with limited access and privileges to perform scripted tasks that they would otherwise be unable to execute, such as exporting or deleting records. Access privileges do not change, but the script can do more privileged work for them. Furthermore, full access does not carry over to any subsequent sub-script, unless this feature has been enabled in that script as well."
                      
                I read that line about "Access privileges do not change" as "if the user running the script does not have view access, that does not change..." Maybe the wording can be changed to "The access privileges of the user are not changed, but the script will execute with full access privileges, including access to...."
                      
                Thanks for the help!
                • 5. Re: Find returns records with <no access>
                  philmodjunk

                       Given that the user then gets the records still  hiding behind "no access" screens, I'd say that their "view access" privileges did indeed remain unchanged. wink

                       And I'll add a limitation to "run with full access" that isn't clearly documented in the text that you quoted: The "full access" applies only to the current file. If the data referenced in the script comes from a table external to the current file--which what you get with a solution using Convert to Seperation Model, the access privileges set in the external file are still enforced.