Protecting fields

[Coriolan_66]

Im running a db on my iPad to tracking students projects. Once a project is "closed", I must protect the evaluation fields. Used an old script called "Lock evaluation_field".

If (table_status="closed")

Show Custm Dialog ("Sorry, cannot change the evaluation")

Else

Go to Field (evaluation_field)

End If

Well, the script lets me to alter the evaluation anyway. It doesnt lock the field. I think this script worked for me in the past for FM 10 Pro, as I pointed it out.

Please help me to refine this. Many thanks once more :)

[Russell Barlow]

Well, the script lets me to alter the evaluation anyway. It doesnt lock the field. I think this script worked for me in the past for FM 10 Pro, as I pointed it out.

If this is a script trigger on field entry, you need to direct them to another field or issue confirm record to clear your entry into a field.

[Coriolan_66]

Not clear to me. The script works as if project is "closed", the message will appear, but after I change the value.

Could you be more detailed please?

Thanks

[Russell Barlow]

Could you be more detailed please?

I'm assuming that this....

If (table_status="closed")

Show Custm Dialog ("Sorry, cannot change the evaluation")

Else

Go to Field (evaluation_field)

End If

is a script trigger that is fired when you enter the field your not wanting modified after locking. Your script is throwing a notification that its not able to be changed, but your not redirecting that users entry into that field. So when I click on the field, I've already entered it. Then your script fires and notifies me that I cannot change it, then exits. This leaves me inside the field you don't want edited. You need to add a redirection from that field, or confirm records.

If this is not a script trigger, explain how your using the referenced script?

[Ron Cates]

If it's a drop-down list and you are using onObjectModify, the script will fire after the value is already changed. Add a revert record step. Or if you use an onObjectEnter script trigger, adding commit record step will throw them back out of the field as well.

[Steven H. Blackwell]

All of which does nothing to protect the field from being changed. Look at Access Privileges.

Steven

[capsprojectos]

An easy way is to apply two layouts, one for editing records and other to see only. It’s a fast method, so when the project is closed it jumps to other layout, so the fields are "protected".

Other idea is to have different privileges sets (security side). Best way to protect like as told by Steven Blackwell.

[eos]

The easiest approach to me seems to be the one that Russell Barlow suggested in his two posts.

In his sample script, after the Custom Dialog step add a "Go to Field", with no target field specified,

which is the same as clicking outside of any field:

If (table_status="closed")

Show Custm Dialog ("Sorry, cannot change the evaluation")

Go to Field [ ]

Else

Go to Field (evaluation_field)

End If

As shown above, even the Else part is not necessary; since the user has entered the field,

doing nothing will leave him inside it.

Faster to set up than Access Privileges, and easier to maintain than two layouts (unless you need to

protect a number of fields).

[Vaughan]

In his sample script, after the Custom Dialog step add a "Go to Field", with no target field specified,

which is the same as clicking outside of any field:

If (table_status="closed")

Show Custm Dialog ("Sorry, cannot change the evaluation")

Go to Field [ ]

Else

Go to Field (evaluation_field)

End If

No, no no no.

This was bad practice back in FMP 6 days, please do not start recommending it now.

Use Commit Record/Request.