There are a number of ways to get this behavior. A few that come to mind:
Field Validation on the fields that you want to "lock in" (validate with a calculation)
Control through layout and scripting. This could be done in the same layout, or by switching to different layout entirely. This is easy enough to do with script triggers, but may not fit your solution. Also if the data is accessible via other means (api or another interface file) then it might not fit.
You could also switch logged in user to another user with less privileges... but then you would lose information on who was logged in making changes, if that's a concern. Which it probably should be.
Those are just off the top of my head, there are probably lots more.
Thanks for the great input Mr. Duncan. A little more information...
Techs are to use iPad in the field if that makes any difference.
I have fully scripted out a disconnected solution for the iPad meaning I track last updates and the like when they connect back to the master DB...
The validate idea did cross my mind and if seemed like a lot of hoops to code. I come from a Windows programming and I guess I am a bit spoiled in that you can script objects to enable and disable them... I could write validation that says if ArcFlag = 2 then change it back or something like that, it will be a little complicated with handing the disconnected DB and Sync process...
You could use OnObjectEnter script triggers.
why not just use a script trigger in your layout. Set the onRecordCommit trigger. Write a script to evaluate your flag, if the flag is set when the user tries to commit a change the script stops the commit from happening. perhaps just throw a dialog onto the screen notifying the user they cannot change any records. Or even better, display the Archive Flag in the footer/header or something that tells the user that the file is no longer editable.
this is a simple example script, yours may need to be more complicated or have different commands based on your project but the general idea is this:
if (Archive = 2)
Revert Record/Request[No Dialog]
I guess its not super elegant because the user can still click into a field and change the value, but it wont commit changes and thats what really counts.
ding, ding ding!
I think Mr.Ms.Mrs.... ghk... has an answer I am willing to implement.!
Thanks for all the input. I will probably combine that with conditional formatting to grey down the text in the fields as well when ArcFlag = 2. again great ideas, what a group of minds, it is almost scary.
Apologies if I've missed something here, but have you considered FM's RLA (record level access) controls implemented through Privilege Sets (File > Manage > Security)?
I would definately leverage the security model so that if the archive flag field = 2 user can not edit the record.
If you try to implement security by other means it is almost guaranteed that a user will find a way to make it do exactly what you do not want no matter how thorough you may be.
This idea sounds very intriguing; however it is not apparent to me how I may implement this to achieve my goal. Let me elaborate...
First off this is a Microsoft Dynamics SL integration project to enable our field techs to enter Sales Order info and avoid a lot of double entry stuff. Another note is that in Dynamics SL they are “Sales Orders” and when in FileMaker we refer to them as “Work Orders.” Really the same but as a Sales Order the data is validated and consistent with Dynamics SL and as a Work Order I have a little more freedom…
A Work Order is "synced" to FileMaker Server and ultimately to the iPad (just the header record.) Header holds billing and site info as well as local contact and will hold the captured signature. Through the progress of the work order the tech will add time to the work order on a labor table (tab with portal tool to labor table.) and also Material and Description tabs with corresponding tables and portals. All these tables have an “ArcFlag” field and currently the possible values are 0, 1, and 2.
0 – Record is in financial system and ready to be imported to the FileMaker and become a “Work Order”.
1 – Record as been imported and is “In Progress” status (Work Order.)
2 – All Entry is completed and customer has signed the Work Order.
When the “2” is applied it is applied to all related records and I need our system to prevent any possible modifications to the records as this would invalidate the signature process… I originally created a duplicate set of tables and simply copied records from the Work Order tables over to a set of Archive tables. The Layouts for the Archive tables would not allow edits however this provided some serious complications with my Syncro code to keep the iPads in sync with the FileMaker Server.
Normally I would have set an “enable/disable” flag on each control on the layouts based on the ArcFlag but shortly into this project it became apparent that there is no such setting in FileMaker (a bit of a shock but it is what it is.) So I created the duplicate table scheme. This played havoc with the Insert, Update, and Delete scripts that I created for the sync process and while attempting to work through that I decided to post hear to see if I was missing something simple…
As you described above record level access sounds great but it does not appear to evaluate each record separately… This could be my ignorance as I first touched FileMaker last month and have tasked myself with this project so it has been an education in progress.
Personal background, I have an extensive background in Windows C, C++, VB and have instructed many classes for Microsoft on their SQL Server. I pretty much dropped out of the programming world when the “.Net” stuff came out and focused on SQL Server and Dynamics SL.
Well after writing the above Novel...
I found the security settings that you referred to (additional clicks) and YES! It appears that I can achieve what I need and quite easily. This should work "Lots Gooder!"
forgive my grammer, I majored in Home Brewing in College.
Can't say I know ANYthing about MS Dynamics SL, but not sure it affects RLA, either. Glad you found the settings. Here are a couple of snapshots that might help:
In the above, a record can only be deleted if the QA_ReleaseDate is empty; although you don't see it here, the same is true for record editing. Elsewhere, we provide special privileges to "reverse" the QA_ReleaseDate being filled in - for instance, if someone puts the date in the wrong order, or (for this client) they really need to go back and change older data. Similar conditions can be set for "child" records, if necessary.
This second snap is regarding layouts; notice that you can disallow editing records on a layout-by-layout basis. But please remember that you will need to control access to alternate layouts for this to really enforce what (I think) you are trying to do.
PS - Hopepfully the images came through this time.
Message was edited by: debi