13 Replies Latest reply on May 11, 2016 4:32 AM by Mike_Mitchell

    Forcing Idle Users to Commit

    sarahs

      Title

      Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)

      Post

      In a large new client (50 filemaker 10 windows workstations split over two physical locations, one connected via terminal server), we have run into a major inconvenience to our users - locked records caused by a user editing a record and walking away before committing. We have confirmed this is solely user caused (no missing commit records in our scripts) after extensive testing and recording. However, despite warnings of the importance of exiting records and logging out any time the computer is left unattended, the users are still forgetting often enough to make this their biggest complaint. This is a health care product and despite this being a HIPAA violation with fines starting at $10,000 for the offending employee and doctor, the users just are not making this change in their behavior. We've been looking at ways to trigger (a) auto-commit an idle user's work and if possible (b) run our internal logout script (goes to our login screen, filemaker is locked, but remains open for quick restart) if a user has been idle beyond a certain length of time.

       

      In a previous Warning before being disconnected from FM server's idle timeout feature, the moderator TSGal recommended that:

      However, you may want to look at the script step "Install OnTimer Script".  This will run a script at a specified interval.  Therefore, create a script, COMMIT, that only has the command:

       

      Commit Records/Requests

       

      Then, as a Startup script, have it execute:

       

      Install OnTimer Script [ "COMMIT" ; Interval: 1800 ]

       

      This way, the COMMIT script will run every 1800 seconds (30 minutes).  Therefore, assuming your idle timeout is set to something greater than 30 minutes, if someone walks away, the data will be saved.

       

      I've implemented a version of this in our extremely large database solution (over 50 files, thousands of fields per file, hundreds of layouts per file) that commits the record in each file (we want to automatically unlock a record and let another workstation edit it if an idle user locks it for a certain length of time) , but our QA team noticed a huge problem with it. Namely, any user who is currently typing when it is run has the focus removed from their field. So in the middle of typing, the field suddenly loses focus and you have to click it in to start typing again. Incredibly disconcerting for a user...

       

      I've tried recording the currently active field and return them to that field, but it does not return them to the place in the field they were and that could cause huge user input issues. Script triggers tracking how long a field has been edited and the length since the last keystroke would be impossible to implement, due to the sheer number of layouts and fields we have.

       

      Is there any way to link the idle timeout feature on the server to run a script instead? What we would really like to do is have a user idle for x minutes prompted with a warning, then all records committed, and logged out to our internal FM login screen. Any suggestions?

       

      We're on FM 10 in Windows - I use FM 10 Advanced, clients use FM 10. Most clients will use FM Server 10, some small clients may connect peer to peer. All use TCP/IP for sharing with no IWP or ODBC/JDBC.

        • 1. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
          HugoLidia
             Curious, why would you want to commit a record that is currently being input by a User without knowing if the record input/changes are correct.  In my opinion, if the user has been sidetracked, then hard luck - "revert" the record thereby removing the focus to enable others to edit it, this way the user learns to finish one job before starting another.
          • 2. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
            sarahs
              

            In a medical setting, that would be tampering with a medical record and could cause some kind of preventable medical error. Would you want a patient's severe allergy to certain medications to be lost without saving? Not a good idea... 

             

            As a medical software developer, we have to follow certain certifying authorities that demand certain behavior and never losing uncommitted data is one of them.

            • 3. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
              comment_1
                

              You could look at when the record was last modified before taking action.

               

               

              BTW, I am curious why this won't do:

              http://www.filemaker.com/help/html/non_toc.46.36.html

              • 4. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                RickWhitelaw
                  

                Good call I figure, but I have a question. How is "idle" defined? The OP's problem seemed to center around partially edited records being locked out . . . users "walking away". Obviously this is truly idle. What about a user who's simply browsing records without doing any editing? I assume this is not considered "idle" but I can't be sure from the help article. Server newb question: if a record has focus but is not being edited, is it locked out?

                 

                RW 

                • 5. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                  comment_1
                     Those are good questions. I don't know the answer to the first one. The answer to your second question is no: you need to start modifying the record (or open it explicitly using Open Record[]) to lock it out.
                  • 6. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                    sarahs
                      

                    I have yet to find any documentation of what the idle definition for the server disconnect if idle X minutes feature is. I do know that the feature discards any unsaved data when disconnecting the user. Our clients would not use it as currently designed for two reasons: 1) you cannot discard medical data without creating an immense risk of causing a medical error, and 2) They do not want to exit out of Filemaker when "logged out" due to start up time - they are taken to an internal log in screen and filemaker is locked (no changing windows, etc). If that server idle feature allowed developers to connect it to a script of your choice, you could do things like put up a warning message with a count down clock, commit all data, and log the user out onto your own internal login screen.

                     

                    The definition of start modifying is incredibly important - if a user clicks in a record, types a letter, then deletes it, that locks the record. Clicking in the field does not start the clock on the record lock (true in FM 6 and earlier), but making any change does lock the record. To our average user, entering something then deleting it feels like they haven't edited anything.Sadly, that does lock the record until they click out.

                    • 7. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                      philmodjunk
                         I think you'd want to somehow mark any such "automatically comitted" records. Comitting a record that is only partially modified could also lead to dangerous medical errors.
                      • 8. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                        TSGal

                        sarahs:

                         

                        Thank you for your posts.  I don't have anything else to add, but I have sent a private message to you.

                         

                         

                        RickWhitelaw:

                         

                        You asked:  "How is idle defined"?

                         

                        Any activity with FileMaker is tracked by the CLIENT (not the server) such as mouse, keyboard, scrolling, etc, and each activity resets the idle counter.  When a client connects to the server, the "time out" setting is downloaded from the server to the client and saved with each WINDOW, so each window can be tracked separately.  Each window checks to see if the idle counter is greater than the server specified time and if so, closes the database window.

                         

                        One other thing to consider here is the network.  OMNIOrb is used separately to make sure the connection between the client and server is active.  If a screen saver kicks in, or the client goes to sleep, OMNIOrb will not be able to see the connection.  OMNIOrb will attempt to keep the connection open for approximately 80 seconds before disconnecting the client from the server.  This becomes apparent when waking up from sleep mode (81 seconds later or 3 days later), the database file displays briefly before receiving the disconnect message.

                         

                        TSGal

                        FileMaker, Inc.

                         

                         

                        1 of 1 people found this helpful
                        • 9. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                          hdawson

                          I'm so glad you posted this link about disconnecting idol users.  I was looking at the discussion because I was having problems with users actually losing uncommitted work when they left their files open too long.  The server was set to disconnect them after 30 minutes, but for some reason they were not having their uncommitted work saved in just one file.  What this helped me realize was that I had missed the checkbox for "Disconnect user from FileMaker Server when idle" setting for just one account in one file of our solution.   Unfortunately that one account is the most commonly used for this particular file, which is only an interface file to a data file which was properly set to disconnect the users.  This was causing a big problem because the disconnect setting was causing the data file to close, but not the interface, which is what was holding the recent, uncommitted changes.  I fixed this setting just now and tested it by leaving a new edit oncommitted and after 30 minutes all the files closed properly and the edit was committed to the database.

                           

                          Thanks so much!

                          • 10. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                            DerekBrown

                                 I have a similar issue.  I solved it by adding script triggers on the common fields that users forget to click out of or commit.

                                 - First I wrote a script that is just a commit record and refresh window called "COMMIT RECORD" (originally used as a "save" button for users to click after data entry)

                                 - Then I wrote a script called "COMMIT RECORD - ONTIMER"

                                 - -  If [Get(ScriptParameter) = "DATE"]

                                 - - Install OnTimer Script ["COMMIT RECORD"; Interval: 20]

                                 - -  Else If [Get(ScriptParameter) = "NOTES"]

                                 - - Install OnTimer Script ["COMMIT RECORD"; Interval: 120]

                                 - - End If

                                 You can see I wrote a couple of parameters depending on the field. As soon as the user enters the field, the timer starts.  For the date field, it shouldn't take long at all to pick a date from the drop down calendar.  For the Notes field I give the user 2 minutes to type and then it commits.  No need to calculate idle time or do anything server level

                                 Comments/criticism welcome….

                                  

                            • 11. Re: Forcing Idle Users to Commit & Unlock Records They Are Editing (but have really walked away)
                              cbishop

                              I have similar complaints in our Post Production management system.  I have pretty much solved this without having to close the database connection of the user.

                               

                              I have the ONTIMER script installed on each window.  If in edit mode [ Get ( RecordOpenState ) > 0 ], It looks at the active field and remembers:

                              1.  The active field's table name, field name, selection start, selection size, field contents

                              2.  The active portal row number, record ID, and record number.

                               

                              I store the concatenated text from all these values into a variable $open_field_data, and also into a global variable $$g_open_field_data if empty.

                               

                              The next time this idle script runs, it makes the same calculation for $open_field_data, then compares to $$g_open_field_data.  If they're the same, that means that the user has been idle (no cursor movement, no edits, same record and field are open) since the last time the script has run (in my case 3 minutes).  The script will then commit the record.

                               

                              This has proven to be extremely useful, and is my workaround to the whole problem with automatic record locking (which I wish I could just disable altogether).

                              • 13. Re: Forcing Idle Users to Commit
                                Mike_Mitchell

                                This issue is bigger than just the inconvenience of a locked record. The bigger issue (as hinted at by hdawson, above) is the loss of edits if users are forced to disconnect. Any pending edits (i.e., the whole reason for record lock in the first place) will be lost if a user is disconnected prior to the data being committed, including a forced idle disconnect or just a loss of power or network.

                                 

                                sarahs wrote:

                                 

                                Namely, any user who is currently typing when it is run has the focus removed from their field. So in the middle of typing, the field suddenly loses focus and you have to click it in to start typing again. Incredibly disconcerting for a user...

                                 

                                Your devotion to UX is admirable.  

                                 

                                You can deal with this glitch by using your own idle timer. Set a global variable equal to the last timestamp the user pressed a key or clicked. (You can do this using various Script Triggers.) Then, when your OnTimer script fires, have it check the global variable for the last timestamp. If that value is greater than whatever idle interval you want, then commit the record. Otherwise, just exit the script.

                                 

                                It's not quite as good as the server-based idle timer, because mouse movements won't be captured. (There's no OnMouseMove trigger.) But it should address the issue of committing while a user is typing. (You really don't want that; it can overwrite good data with "fat fingered" stuff if it fires at the wrong time.)

                                 

                                HTH

                                 

                                Mike

                                1 of 1 people found this helpful