locking fields after data entry

[facabo]

Hi everyone,

 

I have database where my employees enter data, but i don't want them to change a field if it is not empty, as this field is key for searches and other stuff.

 

Database

   name: historical

         field name : event

         type : text

         options : indexed

 

Layout

        field name : event

        control style : pop-up menu

 

When the record is created the user selects the event from a pop-up menu, but the record has other fields, and the users modify this information several times after the creation of the record, but if the modify this key field all searches go bad.

 

What can i do so the users can't modify the field event if is not empty?

 

 

Thanks in advance for your help

 

Faustino

 

[LaRetta]

Hi Faustino,

 - - - THIS POST ERRONEOUSLY addresses RECORD changes not field changes.  See next post instead. - - -

This is a job for Security.  I have attached a sample file showing how you can handle it.
 
Create a privilege set (or update your existing newly created data-entry privilege set) by selecting Privilege Set > Edit and opening popup on Records and selecting Custom.  Select the table and below, change Edit to 'limited'. You want to produce a boolean true (or 1) to allow edit so the calculation might be:
 
IsEmpty ( Event )
or
Get ( AccountPrivilegeSetName ) = “[Full Access]”
 
… this second line provides you the ability to correct behind the scenes in case something has gone wrong – you must allow someone that ability.  You may already have a special privilege set for Managers where they might be allowed this type of edit. 
 
If you haven't worked with privileges before, it can be a bit strange so I'm attaching an example (please see File > Manage > Security and the Temp account I created).  Go to Privilege Sets tab and when you select Edit and then Records Custom Privileges, you must select it again to pop up a second edit box and the same when clicking the 'limited' … you must select it again to pop up the calculation dialog box.  That is why I thought an example might be helpful ... I find these behaviours of the popups unfriendly.  So sign in as temp/temp ...
 
The data-entry account is:
Account Name: temp
Password: temp
 
The full access account is:
AccountName: admin
Password: admin
 
I am a bit concerned about the apparent fragile nature of a changed value in this Event field where you say 'if they modify this key field all searches go bad'.  If you explained more of this process, we might have other ideas to assist you there.  

 

And welcome to FMForums!  If you are no longer on version 10, you might also want to update your profile to reflect 13.  :-)

popup.fmp12.zip

Edited June 17, 2014 by LaRetta

[LaRetta]

Oh wow ... locking FIELDS after data-entry, not locking RECORDS.  My apology; it is very late for me.  Well, if anyone needs to understand security with limited privilege sets, this will do it.

 

Now the issue: To prohibit modification of a single field, attach script trigger to the field.  Popups will not fire script OnObjectEnter (although you can set variables with its script parameter); neither will they fire OnObjectKeystroke so instead we will attach the script to OnObjectModify. Script would be similar to:

Set Variable [ $sp ; Get ( ScriptParameter ) ]
If [
  not IsEmpty ( popup::Event )
  and
  popup::Event ≠ $sp
  and
  not IsEmpty ( $sp ) ]
Show Custom Dialog [ OK ; “You can not change an Event” ]
# … uncheck Commit on the custom dialog by OK
Set Field [ popup::Event ; $sp ]
End If

Attach this script to the Event field as a script trigger OnObjectModify and in its script parameter, put: 

 

Get ( ActiveFieldContents )

 

BTW, I don't like to use Revert Record/Request here because it would revert all of the User actions since their last commit and all we really want to do is 'revert' the Event field's value.

 

So now what happens is that the User tries to change the Event value.  The active field contents (before the change) is loaded into the script parameter and then the script compares that prior value to its current field value.

 

 

 Please ask for clarification if needed and I hope this is right - my mind is fading fast.  A pleasant good night. 

 

Oh, and as said when using Security, you will need to allow someone on your team the ability to correct the field on the backend.

Also note that the modification timestamp on this field will change even though the value has been reset to the prior value.

[LaRetta]

There is also the question of 'when is AFTER data entry.'  This assumes that, even on initial record creation, once they enter a value in Event and leave the field, they cannot change it again.

 

In all, what I said originally holds ... I am concerned about the functionality you presented about it being 'bad' if that record field changes.  It would help to know what exactly happens on why that field must be so heavily protected from change.