Lock/unlock all-but-one

[Wikisnoodle]

I've looked at several lock field solutions and not found one that solves my problem without a huge amount of work/number of extra objects.

I have 4 layouts (RA, FA, RO1, RO2 / table = RAFARO) displaying over 200 fields between them (2 layouts contain several tabs).

There will be one privilege set with 20 users.

The client has just told me that he wants a tick in the 'Job Completed' field (in another table) to lock all-but-one of the 200+ fields (he didn't tell me that before!) and, believe it or not, the job can be uncompleted by unticking (unlocking all fields).

Is there a whole record locking method that allows for a single field to be left unlocked?

[bcooney]

I must say that your data model does not sound correct. One table with 200 fields is a big red flag. Certainly, there has to be an opportunity for a child table.

That being said, you could use RLA to only allow edit if Job Completed is empty. You could also duplicate the layout and turn off Entry in Browse Mode for all but one field. Navigation scripts would take the user to either the "locked" or "unlocked" layout (script trigger perhaps on the Job Completed checkbox?)

[brian rich]

I'm progressively upgrading a number of legacy databases which sound similar to yours, and having 200 fields is not unusual! For example we need to lock 'closed' works orders once certain conditions had been met, and this has to happen without user intervention.

'Locking' the record by switching layouts as suggested by bcooney is the approach that i've taken and so far it has worked well. You set a trigger script to run on the on RecordLoad and onLayoutEnter events for the two layouts you want to switch between. It works well; you can even have both layouts on the layouts menu and it will switch to the correct layout even if you select the incorrect one.

I've added a generic script I use below.

I set a local variable called $closed according to the record conditions I use to trigger the layout switch - in your case it will be the Job Completed checkbox. This is then used to detemine which layout is used when.

The persistent $$triggersLock variable is used for testing purposes. When developing, I disable the first If statement and enable the two lines after it. You can now add the script triggers to the respective layouts; the trigger scripts will exit false and therefore not work for everyone. Use a script to set $$TriggersLock = true for you, and you can test the layout switching out. Once you are happy to roll it out, enable the first IF statement and disable the two lines after that. The switching will now happen for everyone. If you want to switch it off for development purposes, just set $$TriggersLock = true for yourself.

Once we implemented this, we did get requests for some users to be able to edit locked events. We provided a password protected script that you could run on a locked record which set the persistent variable $$editUnlock = the UID of the record to be edited. This then makes this record editable temporarily, and relocks it again as soon as youedit another one.

# [trg] Switch Works Order Layout as required

#==============================================

# Purpose: Switch between Locked and Unlocked WO layouts dependant on WOTS status

# Parameters: none

# Called by:

# Author: Brian Rich

# History: Created:: 05/09/11

# Notes: Will need to be triggered for onRecordLoad and onLayoutEnter for following layouts

# Works Order (normal editable version)

# Works Order Locked (non user editable version)

#==============================================

#

# this trigger will be bypassed if $$triggersLock is true

If [ $$triggersLock ]

// # this trigger will be bypassed if $$triggersLock is false ( for testing purposes)

// If [ not $$triggersLock ]

Exit Script [ ]

End If

# Check for WO closed using value of Works Order Closed New from Works Order tracking system

Set Variable [ $Closed; Value:(Works order tracking system::Works Order Locked and $$editUnlock ≠ WORKS ORDER::Works order number) ]

If [ $closed ]

# Locked version of WO

Go to Layout [ “Works order Locked” (WORKS ORDER) ]

Else

# unlocked version of WO

Go to Layout [ “Works order” (WORKS ORDER) ]

End If

Exit Script [ Result: True ]

This appears reliable but I'm sure someone can improve or user-proof it further.

We considered implementing a permissions system to lock or unlock the record, but thought this impractible because there are about 80 other legacy databases which interact with this one - yes - the databases have been around for a long time!

HTH

Brian

[Steven H. Blackwell]

'Locking' the record by switching layouts...is the approach that i've taken

The problem is that this does not lock the record. The UI is not part of the security schema. If you really want to lock it against changes, then you have to do it with permissions in Manage Privilege Sets.

Steven

[Wikisnoodle]

There are several other tables, this is just by far the biggest - and far too late to redesign.

I could get my head around setting up two privilege sets, but couldn't get my head around applying it to my situation. I couldn't work out from the example how a users privilege set could be changed without interrupting their workflow.

Thanks for the suggestions, too late in the day to try anything now - it'll be a maybe tomorrow. But will have a go with duplicate layouts.