Lock (and unlock) editing of record

[Bill_misc_IT]

I have a Filemaker solution for creating purchase orders in my company. Currently, all users who are authorized to create POs have Data entry access. I'd like to improve the security, so that records cannot be accidentally edited after they are 'locked'. I'd like the users to be able to turn this feature on/off, as in make the record editable or not. This will require an intentional step before they can edit, thus eliminating accidental editing.

I created a boolean field named 'locked'. I changed the security so that editing is limited to 'locked=0'. I'd like the users to be able to change this 'locked' field from 0 to 1 (and vice versa), so that they can edit a record when necessary. Unfortunately, when the field is changed to '1', they cannot change it back to '0' because of the privilege. Is there a simple way around this, without involving the admin?

Thanks,

Bill

[comment]

Well, it's not really a security issue and could be handled more easily by layout measures - for example, you could place 2 sets of fields within a tab control, with only one set being enterable.

Unfortunately, when the field is changed to '1', they cannot change it back to '0' because of the privilege. Is there a simple way around this

They could toggle the field by script, set to run with full access.

[LaRetta]

Well, it's not really a security issue and could be handled more easily by layout measures

I quite like the idea of the flag field (in this instance). Handling it in Security with a flag will globally work in all layouts for the table and not just within a tab specified. It is much easier to implement; no need to duplicate objects and fields (or even use a tab for that matter); no worry of making the two tabs 'stay in alignment' if changes occur.

The only down side I can see at all is that the flag will have to be readily available via script. :-)

[comment]

The only down side I can see at all is that the flag will have to be readily available via script. :-)

I am not sure I understand that.

The down sides that I see is that - like with any flag field - the modification of the flag field (1) modifies the record and (2) it modifies it for all users. The (2) part, IMHO, is a deal breaker in the current case.

[comment]

It's amazing that one cannot divide a sentence into a and b parts without running into issues with either emoticons or things in bold :

and ( it modifies it for all users.

and it modifies it for all users.

[LaRetta]

If a User unlocks to modify the record then they possess it anyway so the flag modifying the record and making it unavailable to other Users is no different than the User taking possession and modifying the record directly. At least that is what I perceive here ... I can be wrong.

What I mean by the 'only down side is flag must be available via script' is that records aren't just modified in their standard 'data entry' screen (oh if life were so simple). You can have a customer phone number placed on an Invoice layout and allow modification. If toggle is required before modification then this toggle would need to be accessible on that Invoice layout before the User could change the Customer phone number. So anywhere a table's records can be changed by a User (including portals?!) would need toggle script set to full access.

I would worry more about User forgetting to lock it back up and thus neutralize the good attempt. Maybe lock it back up using trigger on Commit after the record reaches a certain stage of 'doneness'.

LOL on the formatting issues ... don't we just love technology!!

[comment]

records aren't just modified in their standard 'data entry' screen (oh if life were so simple). You can have a customer phone number placed on an Invoice layout and allow modification.

I believe it just stresses my point that this is a user-interface issue - and should be solved at user-interface (i.e. layout) level. If you don't like the tab control approach, you could use script triggers (or even make the fields themselves buttons).

[Vaughan]

I've done this by making a global field to store the ID of records that are UNLOCKED. By default all records are locked. A script puts the record id into the global field: the RLA security checks whether the id is in the global field and if so the record can be edited. To lock the record again a script removes the id from the global.

Because a global field is being modified the records remain unchanged.

There is some complexity, however, in the management of related tables. Also be aware that FMP does not allow the creation of new records to be conditional, which also affects related tables.

[comment]

So why is this a good thing?

[Vaughan]

Huh? It allows records to be locked and unlocked by user without modifying the records.

The complexity has nothing to do with the locking technique, it relates to all record locking situations where there are related records.

For example, a contacts record has a join record to a course. This join record can be seen from both the contacts and the courses contexts. Under what conditions should it be editable: when the contact record is unlocked, or when the course record is unlocked, or both?

[comment]

The complexity has nothing to do with the locking technique

I think the complexity has something to do with the decision to handle this through account privileges.

Under what conditions should it be editable: when the contact record is unlocked, or when the course record is unlocked, or both?

Continuing in the same vein, the question doesn't rise at all when you look at this as a UI issue to be solved at the layout level.