User specific protected fields

[OneTime]

I just finished setting up a very basic Work Order control DB. I am trying to ensure that all work orders used get either billed or canceled. I have only created 5 or 6 FM DB in the past and the server and user security settings are always an issue for me. Basically, what I am trying to obtain is that User A to be able to click the buttons that will generate a Work Order number for either series, but User B cannot. Also, I have a layout that shows all unbilled Work Orders (only shows records with empty Bill Date and Cancel Date fields) that both User A and User B should be able to see and search and sort, however I only want User B to be able to enter information in the Bill Date and Cancel Date fields thus providing the managerial check and balance. I would have uploaded the file, but apparently I am not permitted to upload .fp7 files.

Any help would be greatly appreciated. Cheers.

[doughemi]

Create Accounts for each user in File->Manage->Accounts and Privileges. Then create Privilege Sets that will not allow B to enter the fields.

For your buttons, add If( Get(AccountName) = "UserA_Account") to the button script.

To upload files to this forum, zip them first.

[Josh Ormond]

Privileges will let you allow or disallow data modification on a Record level basis...which is usually enough.

If you need to prevent entry on a specific field, but still allow entry to the other fields...you have a few things you can do ( others may have other ideas too ):

• Place the fields on another layout ( or tab ) that only certain users have access to.
  
• Use an OnObjectEnter script to Commit Record ( or Go to Next Field or Go to Object, or something else that gets them out of the field ) when the user name or privilege set meets a certain condition. ( and maybe show a Custom Dialog to inform them why they can't enter that field.
  

[LaRetta]

As Doug points out, field level access can also be controlled using Custom Privileges, selecting the table and then the field to set as limited. Sometimes it is important to keep User out of a field. If so, use Security because you want to restrict access no matter the entry point.

But sometimes, layout-level restriction is all you need; it is certainly a nicer experience. You can do both - start with your script trigger which can intervene with nice explanation and your Security can protect the data from back doors.

[Josh Ormond]

For important fields, that security is vital...I almost always go with not having the actual field on the layout. And include an "edit" tab/layout that is restricted via Security and access only via a button.

Thanks LaRetta, great points.

[OneTime]

Thanks everyone for your input. The data security for this is not super sensitive so I think I will use a hybrid of the GetAccountName function into the button script to limit access as well as do mirror layouts with slightly different fields available.