I cannot seem to reproduce this. In fmpa14 on win7.
I set up a table with three records where InspectorID was 3, and three more where it was 4. I limited viewing of records like you did. For the three records for inspector 4, I see only "?" in the fields. If I perform a find for any value (where I'd normally find all) I only find the three records for inspector 3. It would seem that there are other factors at play.
Meanwhile a thought, though: A non full-access user, with FMPA, can use a let statement in a data viewer to change $$inspectorID. If you use a global field instead, you can still reference the value from anywhere, but that same user cannot change the value in the field without having access through the interface.
Not the best way to implement security based on a global variable. You can secure a global field and I'd use that instead.
My guess is that $$ globals begin to exist after login, while global fields can be referenced even during login (and evaluate to what they were when the file was used locally or to "" if they were defined in a session to the server).
I would use that, filling it with PersistentID (workstation-based) or a user UUID picked up from the users table.
Perhaps you are swimming upstream rather than going with the current.
You are trying to create a Privilege Set based on a calculation.
The Privileges are designed to filter out records based on a calculation for an account.
So if you created a Privilege Set for Inspector 1, 2, 3 and then used the privileges to set the show of records for that inspector, you might bypass this problem. Each inspector would then have their own account and you can work off of that in many ways.
The second best choice, which you are tring to do, would be to NOT create such a privilege set filter but to filter each record as it is opened using a trigger. This would let all inspectors use the same account, Say Inspectors, and each record would then look to see if the current inspector ID is appropriate. However, this is easily bypassed isn't it since an inspector could enter another inspectors ID number and cause problems. Thus securing it with an account name and password as described would make your system more secure.
One example: Using separate account names you would then add to your table definition:
User Account name = Account Name (by one of several methods)
Then your filter would be User Account Name = get(accountname)
Each new record would then be automaticaly stamped by the account name in use by the Inspector.
It would seem that there are other factors at play.
I think you're right. I'm not sure what those factors are, but I moved the loggedin user id, account account name, and privilege set name into my GLOBAL table and it works as expected.
I hadn't considered the security risk (obviously) of having these as global variables.
Globals may persist for a user after the file is closed and reopened. $$Variables do not persist and do not appear until they are declared. If they are set to empty they disappear. You can see this in the debugger.
One real benefit of a gobal over a $$Variable is that the global can be used to create a TO. A variable cannot although its value can be transfered to the global. One real benefit of a variable over a global is that you do not need to go to a layout to change its value.
There's some factual errors here...
When a file is closed locally and re-opened, global field values persist. When hosted, global field values reset to what they were the last time the file was closed locally. I doubt the file is being used locally in the original post.
You can also change a global field without navigating to a layout.
I doubt the file is being used locally in the original post.
Correct - the file is hosted by FMS13.
Yikes. I found out why I could set a global field in the quick test I did: I was just typing in abc and not "abc". At some point I tried 123 and yeah...
When did I first decide I couldn't do that? Maybe it wasn't possible a long time ago and i just kept on trucking.
This will definitely simply this project I've been working on.
This is one reason why I have a mattress glued to a wall so I won't hurt my head...