8 Replies Latest reply on Sep 30, 2016 11:22 AM by ninja

    Reduce chance of inadvertent record changes

    stevaroni

      In looking through audit logs and watching users, I have found that occasionally people get onto a form view layout and unintentionally change data when they are trying to do a manual find. So, I would like to pop up a dialog that asks the user if they are intending to change the record before allowing any changes. Any suggestions on how best to accomplish this? Edit privileges in this table currently limit the ability to edit records to the person who created the record--so this would involve an additional limitation or a trigger.

        • 1. Re: Reduce chance of inadvertent record changes
          justinc

          Is this for clients on Windows?  Until 15 the default behavior of the scroll wheel on windows was to switch records.  There were ways to intercept that function and prevent it...or just move to 15. 

           

          Here's one thread:  Disable Scroll Wheel

          • 2. Re: Reduce chance of inadvertent record changes
            philmodjunk

            This is a long standing consequence of FIleMaker's Find Mode being accessible to general users.

             

            One option is to create your own scripted find system where the user's click a button or enter find mode and a Popover or window opens with global fields to be used by the user for entering search criteria. This has the added benefit of allowing you to format the fields with value lists, etc customized to search criteria entry rather than basic date entry. A "find" button in the popover or window performs the script that does the find. You can then deny find mode access to the fields on the layout itself via the inspector's data tab.

             

            Another option is to deny browse mode access to the fields on the layout and put an "edit" button o the layout that opens a different layout, window or popover with fields for editing. Sometimes, this is even a set of global fields into which the data has been transferred for editing with a "save" button that transfers the data back to the record in order to "save" the changes. This give you an easy way to "cancel" the edit by using a button that simply returns the user to the original layout (or closes the popover) without transferring the data from the global fields.

            • 3. Re: Reduce chance of inadvertent record changes
              justinc

              Hmmm...re-reading your question and I realize I was addressing the wrong problem. 

               

              See Phil's suggestion.

              • 4. Re: Reduce chance of inadvertent record changes
                StephenWonfor

                Stevaroni

                 

                Rather like Phil said.

                 

                Another possibility, depending upon solution complexity is to do this.

                Use scripted navigation to go to a form layout with no browse enterable fields.  You could then use a script trigger on the layout to switch to the browse editable layout when a new record is created.

                 

                Stephen

                 

                "Hollywood is difficult to navigate if you have integrity, so I opted not to work if there wasn't enough to do in a role..."  ~Robin Wright

                • 5. Re: Reduce chance of inadvertent record changes
                  coherentkris

                  This can also be solved by providing clear indications of the users current mode and training

                  • 6. Re: Reduce chance of inadvertent record changes
                    scottworld

                    Why not just turn off automatic record saving for the layout? Then, FileMaker itself will always prompt the user if they're sure they want to save the record. (As long as you don't override this behavior with a script.)

                    • 7. Re: Reduce chance of inadvertent record changes
                      gofmp15

                      One other method is to use a layout where the fields are not editable but you can do finds. This eliminates the problem described. Now if a user wants to edit a field, add an Edit or Modify button on the layout and move them to a layout where certain fields are editable and perhaps use a colored border or background to indicate they can be edited.

                       

                      I have used conditional formatting to color empty fields a nice light color to remind the user that data is needed here.

                       

                      The condition might be something like isemtpy(self) and use a light pink or green, etc.

                       

                      You might also test this idea, use a conditional to show a modified field and color it red. This would alert the user the field was just modified.

                      • 8. Re: Reduce chance of inadvertent record changes
                        ninja

                        FWIW, I ran into this face first with a new user facility...

                         

                        1. spending 30 minutes filling out a complex record, then having all your work disappear into the box "No records match this find criteria". and only then realizing you were in find mode

                        or

                        2. Overwriting key information thinking you were in find mode...

                         

                        For their layouts, I rebuilt with a full coverage item (filled rectangle) on the bottom of the stack, then turned it bright pink if Get(WindowMode) = 1

                        I left it there for about a month while people got used to navigation and increased their comfort level...now it just turns pale yellow (less annoying but still clear) and the errors have stayed gone.

                         

                        HTH