I have implemented a field based record edit lock using the regular privileges, but the message it provides to a user who tries to edit a locked record is rather cryptic ("your privileges do not allow this")

Is there a way to trap a privilege failure and offer a better dialog/user explanation?

(like: You cannot edit records fro jobs that have been completed. Contact your supervisor.)

Thanks in advance,

Justin

I'd like that too, but AFAIK the answer is no.

I have implemented a field based record edit lock using the regular privileges, but the message it provides to a user who tries to edit a locked record is rather cryptic ("your privileges do not allow this")

Is there a way to trap a privilege failure and offer a better dialog/user explanation?

(like: You cannot edit records fro jobs that have been completed. Contact your supervisor.)

Thanks in advance,

Justin

First, find out what error is generated. It might be 3 or it might be in the 200 range. The play around some with an event trigger to see if you can trigger the error, suppress the default message, and then substitute your own custom error message. Don't know for sure whether this will work, but it might be worth a try.

Steven

First, find out what error is generated. It might be 3 or it might be in the 200 range. The play around some with an event trigger to see if you can trigger the error, suppress the default message, and then substitute your own custom error message. Don't know for sure whether this will work, but it might be worth a try.

Steven

I did try to trap an error message just using the DATA VIEWER (since this is not a script) window with a Get ( LastError ) refreshing after the dialog is dismissed, but could find no evidence any error number other than zero is generated?

Do you think thats likely, or is my test just insufficient?

Cheers,

Justin

I did try to trap an error message just using the DATA VIEWER (since this is not a script)

That's not going to work. The Get (LastError) function returns error generated by a script step. If no script step was performed, the function will return 0.

The general idea of triggering a script and then capturing an error is not going to work either, IMHO. The reason for this is the timing sequence:

In order to trigger a script, user needs to try and modify the record. This will not generate a script error (since no script is running yet). It will, however, throw up the "Your access privileges do not allow you to perform this action" error message. Only then will the script itself run - if at all (depending on the exact triggering event).

Instead, try attaching a OnObjectKeystroke script trigger to the layout's fields, triggering the following script:

If [ Get ( AccountPrivilegeSetName ) ≠ "[Full Access]" and YourTable::Completed ] 

Show Custom Dialog [ "Can't you see this record is completed?" ] 

Exit Script [ Result: 0 ] 

End If 

ScriptTriggers are great for this sort of thing.

Also a nice touch is to add a conditional colour background to the field to indicate that the field cannot be edited, or in the case of a 'locked' record a 'watermark' in the background on the layout gives the user instant feedback that the data is locked. Consistency is the essence of this though, and you have to make sure to follow the 'rule' across the whole database (e.g. grey fields & dark grey text not editable, but cream fields with black text are).