have you considered using a $$state variable in your locking as well?
appointmentStatus = "Unlocked"
$$state = "Unlocked"
Then, instead of using a field value, you can use a session variable that is set at the beginning of your script and reset via an OnRecordLoad trigger (to re-lock everything when you're done). this would also negate the need for you to run a script with the full access.
I'd love to say I've tried this and it's worked, but I'll admit I haven't put it into practice.
Let me know offhand if this does work, would be nice to demo it at COFMUG if it does.
Thanks Mike. Not clear how this would help. Perhaps you can attach a sample file?
Speaking of which, I've added two sample files to my original post. LockedRecord_pum.fmp12 attempts to change the status of the record by using a pop up menu (pum). LockedRecord_btn.fmp12 attempts to change the status of the record via a button (btn).
There are two accounts: Admin and Jdoe. There is a new Privilege Set: "Admin" (in retrospect, this is confusing - I should have named the privilege set different than an account). Security is set up as such:
Admin Full Access
A script enables quickly toggling between accounts.
The issue is that when logged in as Jdoe there is no way to change the status of the record from "Locked" to "Unlocked".
I was just theorizing that state variables are exempt from the record conditions of which your privilege sets are being constrained by.
I've done a quick sample here though,
Admin || -no pass-
test || pass (custom priv set)
See if this is anything close to what you need. The button "unlocks" the record, and the lock resets on open, and OnRecordLoad via a trigger.
sample.fmp12.zip 11.2 K
I neglected to run the button with Full Access privileges. That did the trick.
I attached a third file to my original post - LockedRecord_btnFULL.fmp12.zip This runs the button with Full Access privileges, so even logged in a Jdoe I am able to change the data in the Status field.
ah, figures something that easy was the root cause. Still, with the trend of "context free" development, it still might be at least useful to consider the state technique I outlined. Session variables have been extremely useful in more than just the security features.
Thanks Mike. Looks like we simultaneously came up with similar approaches.
Lucky for me you having that problem...
I was looking for advice on a totally different issue (record locking) and Mike Mitchell kindly pointed me here — and I found the answer! My systems do not require much security so I did not even know custom privileges exist. But then again, I have not done much FMP work since version 6.
Interestingly, when a record is locked an attempt to make changes generate (at least) two different dialogs.
Changes to Edit Box fields, deletions etc: Your access privileges do not allow you to perform this action.
Changes to Tick Box fields: This action cannot be performed because this field is not modifiable.
I hope my client never sees these as this is a bit confusing: there is a big red banner in every relevant layout saying that a record cannot be changed.
One thing to be very careful of when using variables in this way...a resourceful user/developer CAN change those variables. And if you are using them to secure parts of the solution, it could open you up to data security problems.
well, ideally you'd be locking down menus and any full-access privileges that would let you execute a variable change as well.
That is a good concern though, thanks for pointing it out.
Joshua made a really good point. I'm pretty sure he's referring to the fact that anyone with FMP Advanced can use the Data Viewer's Watch tab to set a variable in a Let statement. Custom menus do not turn off the Tools menu in FMPA.
Exactly. You can't lock it down entirely (using persistent variables that is).