Lock Field After Initial Entry

[Reid]

Is there a way to lock a field after its initial entry? I just don't want people "accidentally" changing information after its already in the database.

[bcooney]

One way to deal with this is to have a button that toggles a flag_Locked field.

Then, create a rec access rule for that priv set that edit is allowed when flag_locked ≠1.

You may limit the ability to unlock to an Admin priv set.

[Steven H. Blackwell]

You can possibly do this with a script trigger; however that affects on the layout entry. Field level validation my be the route to take here. However this entire process can open up a lot of user interaction problems.

Steven

[bcooney]

I don't see how you could use a script trigger, here, Steven, because, imho, you'll impede data entry.

It is good to point out that you'll need to be careful locking a record from edit. When this user runs a script (and it is NOT set to run with Full Privs), then any edits the script tries to make will fail bcs scripts obey the rla rules too. So, you'll have this edit lock to contend with in your scripts.

[Reinder]

Just thinking out loud....

There is a script trigger 'OnObjectEnter', but it is fired after the field is selected and active.

The only way to avoid entry then is to go out of the field or committing the record.

It can be done from the script, but I am not sure if I should use it.

Committing the record causes trouble when other data is edited and fails its validation.

Going out of the field causes trouble when there is nowhere to go.

And it is only working on the layout and not overall in the database.

Same goes for a button on the field and checking if entry is allowed.

Trying to do it within the validation itself is difficult, because checking with IsEmpty can't be done. How do you know if the data was already there to begin with?

It would be nice to have the possibility to validate for empty and not empty status of a field.....

Privilegesets can only avoid editing based on a calculation for the whole record, not on a field by field basis.

All in all, I would say it can't be done without some tricks

HTH

Edited November 12, 2010 by Guest

[bcooney]

I read this as locking the entire record from edit, not locking a field, and so I can now see how you could trigger the lock. However, the warning re: scripts and the lock still applies.

Another suggestion. I often "bury" sensitive fields on a record in a popup window with a Done button. This way, the user must click an Edit button to access these fields. This technique is especially useful if you need to run validation when they click Done or only allow certain priv sets to edit these fields.

[Oyseka]

I think that this thread is touching on something that I am trying to achieve as well unless there is a better way of doing it. When an invoice is created the portal brings the data in from the Line Items table and is still editable after the line is exited. I am trying to stop the operator from changing that line item after the initial entry. What has happened is that the invoice is produced for a cash sale and after the client has paid the operator just changes the quantity and pockets the cash difference. I am trying to force the issue of a credit note if a genuine error is made on data entry rather than the ability to just change the portal row.

[NLR]

I think that this thread is touching on something that I am trying to achieve as well unless there is a better way of doing it. When an invoice is created the portal brings the data in from the Line Items table and is still editable after the line is exited. I am trying to stop the operator from changing that line item after the initial entry. What has happened is that the invoice is produced for a cash sale and after the client has paid the operator just changes the quantity and pockets the cash difference. I am trying to force the issue of a credit note if a genuine error is made on data entry rather than the ability to just change the portal row.

In this situation, one way of locking a single field such as the 'Quantity' field on an Invoice is to change it into a repeating field with 2 repetitions. In effect, this hidden second repetition "watches" over what you do with the first...

Redefining the Quantity field also involves using an auto-enter calc. to populate its second repetition with a "copy of the value" that's entered into the first. Then you add field-validation which checks that both repetition values are the same.

On an Invoice layout, only the first repetition is visible. Any attempt to change the 'Quantity' is therefore challenged. I've provided an example file to show how this works. As an extension to this idea, it would be possible to provide a "Please let me" button/script to let a user make a "genuine" alteration - the script could operate in a few ways, one way being that it captures the initial value, the userName etc. (for auditing purpose say), then sets the second repetition to match the first, thereby permitting the change to be accepted.

Regards,

Ralph

Locking_a_Field.zip

[Oyseka]

In this situation, one way of locking a single field such as the 'Quantity' field on an Invoice is to change it into a repeating field with 2 repetitions. In effect, this hidden second repetition "watches" over what you do with the first...

Redefining the Quantity field also involves using an auto-enter calc. to populate its second repetition with a "copy of the value" that's entered into the first. Then you add field-validation which checks that both repetition values are the same.

On an Invoice layout, only the first repetition is visible. Any attempt to change the 'Quantity' is therefore challenged. I've provided an example file to show how this works. As an extension to this idea, it would be possible to provide a "Please let me" button/script to let a user make a "genuine" alteration - the script could operate in a few ways, one way being that it captures the initial value, the userName etc. (for auditing purpose say), then sets the second repetition to match the first, thereby permitting the change to be accepted.

Regards,

Ralph

Absolute poetry, Thank you very much,

Regards

[Steven H. Blackwell]

In this situation, one way of locking a single field such as the 'Quantity' field on an Invoice is to change it into a repeating field with 2 repetitions. In effect, this hidden second repetition "watches" over what you do with the first...

I believe you will discover that this process is flawed and is easily susceptible to defeat by any of several standard attack vectors. It does not provide protection against changing the value once entered. The UI is not the security schema.

Steven

[NLR]

I believe you will discover that this process is flawed and is easily susceptible to defeat by any of several standard attack vectors. It does not provide protection against changing the value once entered. The UI is not the security schema.

Steven

Steven,

With all due respect, I believe you have misjudged the intent of the query given by Oyseka and the response given by me. He asked for a way of stopping an operator from changing the value in a field after the initial entry. Also, in the event that a genuine error had been made, a means by which a corrective action could be performed.

No mention of existing security arrangements was mentioned and no inkling that security needed to be improved was given.

My response was given on the basis that "adequate" security was already in place. Without knowing anything beyond that, your statement that my process is flawed, comes out of the blue, and without anything in example form to support what you said.

You state that it's easily susceptible to defeat… For that to happen, an attack would need to be made by somebody having credentials providing sufficient privilege to the schema, the layouts or to other areas of the file including a second attacking file. So, if the operator is such a credentialled person, yes, it's true the UI is not sufficient.

To answer your concern (as a belts and braces solution), I would extend my method into one that uses a second "Lock" field in place of the second repetition. It's an extra field and a small price to pay for ultimate security. The "Lock" field therefore takes over the job of "watching". To prevent unauthorized access to that Lock field (which is what I believe you are talking about), it's simply a matter of modifying the operator's privilege set to one that enforces "no access" to the "Lock" field.

This means if a genuine error is made, it will require the attendance/attention of a different (more privileged person) to correct the error.

Regards

Ralph

Locking_a_Field_securely.zip

[Vaughan]

You state that it's easily susceptible to defeat… For that to happen, an attack would need to be made by somebody having credentials providing sufficient privilege to the schema, the layouts or to other areas of the file including a second attacking file.

No, it can be done with user-level credentials.

Create a new empty FMP file, add an external reference to the original file (this is the only part that requires authentication) and create a layout in the new file for the external table. Add the fields to the layout as desired. No developer-level accounts are required unless the file uses the new FMP 11 security feature requiring a full access account to create an external file reference.

Data access restrictions on layouts only work ON THOSE LAYOUTS. Restrictions set up at the record access level work universally.

I don't think many people grok that. They don't even know that they don't know it.

[NLR]

No, it can be done with user-level credentials.

Create a new empty FMP file, add an external reference to the original file (this is the only part that requires authentication) and create a layout in the new file for the external table. Add the fields to the layout as desired. No developer-level accounts are required unless the file uses the new FMP 11 security feature requiring a full access account to create an external file reference.

Data access restrictions on layouts only work ON THOSE LAYOUTS. Restrictions set up at the record access level work universally.

I don't think many people grok that. They don't even know that they don't know it.

Hello Vaughn,

I think you must have missed what I said in my last letter: "…To prevent unauthorized access to that Lock field, it's simply a matter of modifying the operator's privilege set to one that enforces "no access" to the "Lock" field."

That protection is given at the field level (within the "Records" area) of security of the original file. Only a person having the required/higher privilege-set can change that Lock field. This protection extends to external files as well. Nothing to do with layouts. You said it yourself - "Restrictions set up at the record access level work universally".

Regards

Ralph

[Oyseka]

Hello Vaughn,

I think you must have missed what I said in my last letter: "…To prevent unauthorized access to that Lock field, it's simply a matter of modifying the operator's privilege set to one that enforces "no access" to the "Lock" field."

That protection is given at the field level (within the "Records" area) of security of the original file. Only a person having the required/higher privilege-set can change that Lock field. This protection extends to external files as well. Nothing to do with layouts. You said it yourself - "Restrictions set up at the record access level work universally".

Regards

Ralph

Hi Ralph,

Having followed the previous posts, I reiterate my comment to your original reply, Absolute Poetry. The purpose of that lock field is to defeat an operator, not a hacker. Fortunately I live in the kingdom of the blind and the solution you provided is certainly enough to defeat the user and force the creation of a credit note if an error has been made which is exactly what I wanted.

Regards

[Vaughan]

I think you must have missed what I said in my last letter: "…To prevent unauthorized access to that Lock field, it's simply a matter of modifying the operator's privilege set to one that enforces "no access" to the "Lock" field."

I was referring to the repeating field method posted earlier, not the lock field method. The repeating field method can be defeated by entering the new value into both repetitions, and displaying both repetitions can be done without full access privileges as I explained. This is because it is relying on the interface to enforce the security.

The lock field method relies on record-level-access security so it is independent of interface.

[Steven H. Blackwell]

You state that it's easily susceptible to defeat… For that to happen, an attack would need to be made by somebody having credentials providing sufficient privilege to the schema, the layouts or to other areas of the file including a second attacking file. So, if the operator is such a credentialled person, yes, it's true the UI is not sufficient.

Mr. Learmont:

Sorry, but as Vaughan points out that's just not the case. Your second example is a whole lot better though. It uses the traditional lock field method with the interesting twist that the value in the Lock Field matches the entry value in the data field, rather than the more traditional 1 or 0. And you've appropriately protected the Lock Field via field level privileges, not by the UI.

This type scenario was one of the use cases we had in mind when File Access Protection was introduced in FileMaker® Pro 11. If you go to the main FMPug.com page in the lower right corner or to here you can download a White Paper I did on this topic.

I hope this thread has been instructive to all.

Steven

[Jakallergis]

Hi there,

Sorry for posting so late after this thread was created, but i came here as i was searching for a way to do something similar, and as i struggled a bit, i now am so happy that i found a solution to my similar problem that i want to post it.

So i have a portal which i use to create new records inside a join table. I create records inside the portal by adding a value to the foreign key field of the last row. So i have a fk field inside the portal which starts empty (last row) and when i enter a value it creates a row (a record) with that value on the fk field, some fields from a relative table, and some fields that i want to input each time (like quantity and price). So after the creation i wanted to make sure that the user cant enter another value to the fk, because that would change the relative fields like product name and barcode, but the fields quantity and price would stay the same. I just wanted a way to lock the fk field after the record row is created but still be able to change values within the other fields of the same record row.

So  what i did is trigger a script when i enter the fk field that checks if the field is empty and if it is, then it does nothing so u can continue typing as normal, but if it isnt empty (like the already created records) it reverts the record to its previous state (which is being empty).

the scrip can be assigned to any field in the database:

if [ not IsEmpty ( Get ( ActiveFieldContents) )]

   Revert Record/Request [With dialog:Off]

End If

Exit Script

So whenever I click inside the fk field of a created record to enter values, it just exits the field without making any change. I know some of you out there will already know 10 better ways to do this, but still this solution is enough to get a newbie like me to the hype train. wooohooo go me  

[comment]

Layout level measures (such as triggered scripts) are not suitable tools for ensuring data integrity. Use either privilege sets or field validation. In this case, as Filemaker security schema does not provide field-level conditional access, you need to use field validation. You can supplement this with script triggers, to prevent user having to deal with validation error messages - but this cannot be your only line of defense.