If you then perform a find with the * operator on this layout manually, do you also get that result?
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 UserIf [ 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?
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.
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!
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.