A script to allow and dis allow editing for all fields in a layout while in browse mode..

[justink]

Community,

I have a DB that I'm working on and I'd like to protect it from being accidentally edited. I'd like to have two buttons where I can switch between an "allow editing to records mode" and a "view only mode" while staying within the Filemaker browse mode. I'm guessing this could best be done by scripting but I'm not sure if there are any ways to turn editing on and off with scripts. Would a script that changes users be possible or would that be too cumbersome? Any ideas or help would be greatly appreciated. Yes, I'm a bit of a noob with FileMaker, so sorry if this is a really basic question.

Thanks in advance

[comment]

A simple solution would have two sets of the same fields on the layout, placed inside a tab control object with two panes. One of the sets would allow entry to the fields.

Selecting a tab can be scripted, and the tab control object can be formatted as invisible.

[datalink]

Another option might be to create two security account. One would allow editing of the data and one wouldn't. Your script could then toggle back and forth between those accounts using the re-login step.

Or complete the layout so that you won't need to tweak it again in layout mode, then duplicate it. On the uneditable layout you can set all the fields to disallow entry in browse mode. Your script could toggle between the two layouts. This would be seamless for your operators. The down side is that if you need to edit the layout you'll have to modify two layouts. You also would want to disable the menu bar for your operators so that they can't just go to the editable one at their pleasure.

[comment]

Another option might be to create two security account.

I don't think you'd want to do that. There is no security issue here. Would you be issuing two accounts to each user? Make users re-login every time they wanted to edit data (losing their session data in the process)? Eventually, you'd have users staying in the "authorized" account all the time (as they rightly should).

[datalink]

@Comment - You make a good point. I had thought to use the re login script step in a script that would allow the operator to toggle back and forth between accounts so it would feel seemless. But the idea that operators will just stay in higher access accounts is a problem.

[Vaughan]

ONe method that I have used is to set up the record level access privileges so that the record can only be edited if the record serial number is in a global field. The record /ock/unlock process is just a matter of adding and removing the id from the global field.

[comment]

But this is a purely layout issue - why manage it through privileges?

[nesor]

We use a similar method to Vaughn's suggestion. Here's why we handle it at the privilege level, rather than with layouts:

The privilege-level control protects your data if you create additional layouts for tables, without the need to manage read-write access at each layout (Seems more efficient to deal with this once per table, rather than on a per-layout-per-table basis). Additionally, it protects data in the event you add scripts your users access that might edit data on records that should be in a read-only state.

[Vaughan]

Wow, I'm being channeled. :D