Jump to content

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


This topic is 4264 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

This topic is 4264 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.