9 Replies Latest reply on Oct 8, 2016 1:13 PM by electon

    Lock Fields based on another Field

    ilabbe

      Morning,

       

      I am working on a database for work and have run into a dilemma. Rather than creating and uploading PDFs so people cannot edit fields is rather ridiculous to me. I am using FMP Advance 14 & 15 to create and maintain the database.

       

      My dilemma:

      We are using a field to indicate if the form is a Draft, Pending, Active, and Archived. Is there a way I can set up so the fields are editable if it says Draft or Pending and non-editable for Active and Archived?

       

      Through some of my readings you can use the IF statement. I am sure this is the only way but any help with the formula would be helpful.

       

      Please do not hesitate to ask me questions, I am here to learn and figure this out so we do not need to use PDFs.

       

      Thanks!

        • 1. Re: Lock Fields based on another Field
          electon

          Without creating either a separate layout or stacked fields with hide conditions you can setup this via the Privilege Set Permissions in Manage Security.

           

          I'd create a separate table for the Status with ID and Name so you can always change the status name without depending on literal text.

          ID     Name

          1     Draft

          2     Pending

          3     Active

          4     Archived

           

          In privilege set choose records, go to your table and for edit choose: limited

          There you can set the condition ( if true then editing is possible )

          Remember to choose from which table occurrence you will evaluate.

           

          If ( yourtable::status = 1 or yourtable::status = 2 ; 1 ; "" )

          • 2. Re: Lock Fields based on another Field
            David Moyer

            Hi,

            I would go about it this way ...

            Have a global text field that you set up with your value list (Draft, Pending, Active, and Archived).  Use radio buttons or pop-up or list to select the new status.  Use the trigger OnObjectModify to fire a script that handles the data entry of the actual status field.  Make the status field non-modifiable on your layouts (e.g. Merge fields).

            1 of 1 people found this helpful
            • 3. Re: Lock Fields based on another Field
              andypieman

              Why not use a separate layout or stacked hidden fields? I would propose that such a solution is less fraught with potential bugs. The users is either allowed to edit, and gets the edit layout, or the editable fields, or they're not.

              • 4. Re: Lock Fields based on another Field
                electon

                andypieman wrote:

                 

                Why not use a separate layout or stacked hidden fields? I would propose that such a solution is less fraught with potential bugs. The users is either allowed to edit, and gets the edit layout, or the editable fields, or they're not.

                 

                Nothing wrong with that option, done these as well. However I disagree on the potentials for bugs.

                Managing two layouts or hide conditions on same layout is more involved than just one calculation in privilege set.

                With complexity, there's actually more chance for error.

                 

                I just proposed a simple solution that will work regardless of what is going on with the layout.

                It's built in on the record level security. You will need Full Access to circumvent that.

                1 of 1 people found this helpful
                • 5. Re: Lock Fields based on another Field
                  andypieman

                  Maybe bugs wasn't the right thing to say. Pinning down security at that level is very final. It would work for this scenario, but if in future there was a requirement to add a signature for an Active document, possibly on iPad for example, the security wouldn't allow it. The whole section would need to be reevaluated, and if the developers had changed it may take a substantial time to find this functionality. Hidden objects are obvious, individual permissions to specific tables aren't quite so obvious.

                  • 6. Re: Lock Fields based on another Field
                    andypieman

                    At the end of the day, there are numerous ways to achieve goals, the one we choose is very much driven by the technical specifications at the time and our own best judgement.

                    1 of 1 people found this helpful
                    • 7. Re: Lock Fields based on another Field
                      electon

                      In this scenario either the record can be changed or not.

                      Modifying data when a record is not editable can be done with scripts that run with Full Access privileges, global fields can be used for capturing data if need be.

                      Scripts ( who can run them and when ) can also be dealt with in privilege sets.

                       

                      It's easy to change conditions for one calculation than multiple hide conditions should the need arise.

                      It can even be built to the status table with a flag field set to one if edits are enabled.

                      A user with sufficient permissions can set the flags...

                       

                       

                      Individual permissions are very obvious, you get a dialog box screaming at you "your access privileges don't allow..."

                      It shows up in DDR as well.

                       

                      We can go on. :-)

                      • 8. Re: Lock Fields based on another Field
                        andypieman

                        It's all about what we're comfortable with, and how we design. I've never been a great technician of the security model in FM (though you've taught me a thing or two in this post), and I try and build app type systems. I don't generally allow users access to standard FM functionality, toolbars, menus etc. I'm happier with hiding layout objects based on custom designed access rights than have a user prompted with a "your access privileges...." that they can do nothing about, or worse ring me to find out what that means.

                         

                        As I say, get 10 FM developers in a room and ask them to solve even the simplest problem and you'll get 10 very different solutions.

                         

                        New to these forums, but not FM. I'm finding it very interesting.

                        1 of 1 people found this helpful
                        • 9. Re: Lock Fields based on another Field
                          electon

                          I'm not in any way trying to argue agains your proposition.

                           

                          Like I said, I use it too and I'm sure many do.

                          I think the basic reason, like you correctly pointed out is:

                           

                          Locking it down on permissions level is the message box with a vague information as to why it happend.

                           

                          I wish FileMaker changed this and I'm sure this is already in the "Product Idea's" section on the forum.

                           

                          I proposed it because:

                          1) by far, the easiest ( to achieve ) and most powerful control of what users can do with the data

                          2) points people to this place that's at the core of FileMaker's security system. And it's quite an elaborate one.

                           

                          I'm glad you found it helpful and informative.

                          Thomas.