9 Replies Latest reply on Mar 14, 2012 8:22 PM by marcosx

    Script Trigger Question



      I have a data entry page that I control access to based on a login account and privilege set.


      I have a calculation that toggles between 1 and 0 , when 1 the data is editable, when 0 it is locked.


      My question is when it is 1 and editable, and the user clicks on the "Next Record Arrow" button in the "Status Toolbar" is it possible to catch that action, knowing that we are leaving the current record, and in reaction set the edit bit to 0 before FM moves to the next record.


      Repating my question from above in a slightly different form - I am trying to create system where users can create a new record and once they leave it,it locks. They can then view the record but there is a decision to edit the record has to be deliberate. The record stays editable until the user leaves the record or says save the record, which really is just toggling the edit bit to 0. The "leave the record" part is what I can't figure out.


      Thanks in advance.

        • 1. Re: Script Trigger Question

          I believe it was Ray Cologon who recently posted a file on this forum demonstrating Lock on Commit technique. So if you turn off auto commit in Layouts and required the user to actively click a Commit Record button that might do the trick. My way is to not allow the user to ever see or use the Status Toolbar and script all necessary events, this makes it easier to trap record commit, etc. You also could

          • 2. Re: Script Trigger Question



            You could try using an onrecordload script trigger and have the script set the value to 0.  It would actually work when the next record is opened,  but I think it would have the desired result.




            • 3. Re: Script Trigger Question

              My advice is NOT to have a lock field in the record itself. When the record is locked, how can the user unlock it?


              Instead, use a global field to store the primary keys of the records that are unlocked. (This has the advantage that merely unlocking a record does not touch the record and change the modification dates.) The unlock process puts the primary key in the global field, and the privilege set checks whether the global has it's primary key value. Locking the record removes the primary key value from the global field.


              Note that the security engine only checks a record's access when the record is first loaded, so after updating the global field you need to switch to another record and back again. This is less painful than it sounds.

              1 of 1 people found this helpful
              • 4. Re: Script Trigger Question

                A simple script that sets the field to 1, run with full access privileges, although I usually trap for a manager's privilege set to let the button to fire the script step. Simpler and easier to keep locked records out of finds if you ever need to do that sort of thing. The modification date seems moot as if one is taking the lock off it's probably to change some data.

                • 5. Re: Script Trigger Question

                  I've just implemented this for a client. They asked for an unlock process before editing any records, which is totally counter-intuitive for FileMaker, but he said, he wants to make sure his employees will not mess up the records.


                  There are several things you need to pay attention to. Below are some:


                  A) Yes, you need a script that does just what you said: unlocks the record for editing, then locks upon next run. But then the user has to be responsible for locking the record before leaving it. I've put in an open/closed lock icon to demonstrate open/locked state.


                  B) You have to make sure child records mimic the state of the parent.


                  C) If your records are in a portal, you can either leave the record open or lock upon selecting the next record.


                  D) what happens when they leave the layout?


                  E) make sure to unlock the record upon creation, otherwise they can't edit the newly created record.


                  There might be more, but these were the Ines that came to mind.


                  Feel free to ask questions.


                  All the best,



                  Sent from my iPad

                  • 6. Re: Script Trigger Question

                    I have found is that users do NOT like the records locking themselves when they leave them. They need the abilty to unlock a record, then be able to change to another (to view or copy come other data) then come back to the original record and not have to unlock it again.

                    • 7. Re: Script Trigger Question

                      We have different clients with different requirements. In my little world data integrity is more important that user convenience. Blessedly FMP is capable of satisfying both needs.

                      • 8. Re: Script Trigger Question

                        bumper wrote:


                        We have different clients with different requirements. In my little world data integrity is more important that user convenience. Blessedly FMP is capable of satisfying both needs.


                        I agree. It is  important to ask what is the purpose of locking records. If it's merely to prevent accidental editing, then this has nothing to do with security or data integrity - and there is no real reason to use accounts and privileges in order to implement such "lock".

                        1 of 1 people found this helpful
                        • 9. Re: Script Trigger Question

                          Thank You for the input, it helped.


                          I am going to show the company owner the two solutions, using the "commit" button and building a global that lists records and see what the preference is.