How to restrict changes on fields

[Carlos Soares]

Hello

 

When i create a layout with my database, the fields are automaticaly ready to receive any changes from the user, and i would like to know if is possible to enter on the layout only to "see" the records, and made any changes only when the user press the "edit" button.

Thanks for your help

 

I´m using the Filemaker 13 Advanced

 

[comment]

See:

http://fmforums.com/forum/topic/68454-script-trigger-to-lock-a-record/?p=324588

[Carlos Soares]

Thanks for the link :-)

 

It´s possible to make a script to change the parameter "Browse Mode" of the field (Inspector-Data)? I notice when i deactivated this parameter, i can see the content of the field but it´s not possible to change the data. Then i can set this parameter off for all the fields and make a button whit a script to activate this parameter.

 

Thanks for the help

[comment]

It´s possible to make a script to change the parameter "Browse Mode" of the field (Inspector-Data)?

 

No, it is not possible.

[LaRetta]

You can use Security to control whether a User can make changes by toggling a global variable FIELD called gRestrict and including that variable FIELD in custom privileges for data access to Records.  Select the table and modify the Edit capabilities to limited, similar to:  not gRestrict ... where gRestrict is a toggle button of:  not gRestrict

 

To make it friendly, you can attach script trigger to all fields OnObjectKeystroke and script can be:

If [ gRestrict]
Show Custom Dialog [ "You can not modify this record." ]
Exit Script [ false ]
End If

Security is the only really safe way, whereas script trigger just allows for nicer message and control.  

 

Corrected 'variable' to 'field' as clarified by Comment in next post.

Edited March 13, 2015 by LaRetta

[comment]

You can use Security to control whether a User can make changes by toggling a global variable

 

I don't think Carlos' purpose is security; it seems it's only to prevent accidental modification. But if it were, then this is important: you should never use script variables (neither global nor local) to control privileges. Users can easily modify a variable's value (for example in Data Viewer, if they have the Advanced version) and circumvent this kind of "security". Use a global field to which the users have no access whatsoever and which can be modified only by running a script with full privileges.

[LaRetta]

You are absolutely correct - my mistake.  I took the script trigger method and mixed it with Security.  Use a global field in security.  Thank you for the correction, Michael.

 

I have corrected my post accordingly.

Edited March 13, 2015 by LaRetta

[LaRetta]

I don't think Carlos' purpose is security; it seems it's only to prevent accidental modification. 

 

 

I thought this as well at first but I decided that it best to mention security since someone might read it and apply it to a situation where it IS critical that it be enforced.   Accidental modification can have just as serious consequences ... accidentally changing an invoice after month-end posting etc.  

 

I like the theory of belt and suspenders.  :-)