Record Locking and Unlocking

[stockingup]

Hi Everyone,

A while back I was searching through this forum (I think!) and I found an article on record locking. I used it in the database Im working on to provide an option to lock a record from being available for editing. As such I now have the following scenario:

Anyone can press a "lock" button that sets a field to "1". In the user privilidge sets, it says that for all users other than the admin account, if that field is set to "1", then editing is not allowed (deleting is restricted altogether).

However, my problem arises with the need to unlock this record again in the future. I made another button called unlock, and made it set the field to "0" which enables any user to edit the file. But, in doing so, some sort of security validation is required. I was thinking of a popup dialog where you enter a password in a password field, and this then gets verified against a parameter in the script. However, this is clearly not secure.

How can I validate a password for this purpose? Where would I store the password?

I'm quite lost on this issue regarding security. All help would be greatly appreciated.

Best Regards,

Jason V.

[Steven H. Blackwell]

First, reverse the number such that 1=unlocked and 0=locked. Makes more sense that way.

Second auto-enter the 1 when the record is created. But for all privilege Sets other than the "privileged" one, set the lock field to be read only. The 1 will still enter.

To lock the record, run a script with full access privileges that sets the lock field to 0.

In order to unlock the field, that is to set it back to 1, a specific user's Account must be attached to a privilege set that allows modification of the field.

HTH

Steven

[stockingup]

Thanks for the reply.

The only problem I see with that, is since there are several users editing the records at any one time, It would be a great inconvenience to have to login as a different user everytime a locked record needs to be accessed. It would be far easier if they could simply call upon the assistance of an admin to unlock it - someone who would know a particular password.

Do you reckon there is a way to achieve that securely?

Best Regards,

Jason.

[LaRetta]

First, reverse the number such that 1=unlocked and 0=locked. Makes more sense that way.

Not to me, Steven. An action turns the flag on. On is 1. Lock is the action. The standard default on all records would be unlock. Just a different perspective, I guess ...

Edited December 8, 2008 by Guest
Corrected spelling

[bcooney]

I second that a flag that =1 is locked!

[robertw236]

There is an option for a completely different approach - using an edit layout. You can control access via scripts and add in the allowed accounts. This approach means that you don't have to deal the accounts privilege sets. It may not work at quite the granular level you're looking for, but it is an approach that I have used and found it quite satisfactory.

[LaRetta]

I am glad you mentioned it, Robert. Using another layout CAN have its benefits at times but it means keeping two layouts in exact synch (which can be PIB) and increases file size.

And welcome to FM Forums! :laugh2:

[Steven H. Blackwell]

There is an option for a completely different approach - using an edit layout. You can control access via scripts and add in the allowed accounts. This approach means that you don't have to deal the accounts privilege sets.

This is completely insecure. It allows anyone to edit the record at any time.

Steven

[Steven H. Blackwell]

Barbara and LaRetta don't like my 1 and 0 configuration.

The default state of the record is to allow editing.

The changed state is to disallow editing.

Editing can occur when the value of the lock field is true. Editing fails when the value of the lock field is false. Hence the 1 and 0 sequence.

If you want to do it another way, that's fine.

Steven

[stockingup]

Thanks for the replies! To be honest, I'm not particularly bothered regarding whether its a 1 or a 0 set for the locked/unlocked records...

However, I'm still rather confused regarding a secure way of having a password entered field to validate this - as opposed to using privilidge sets (as explained above in my previous post)... So far I have a global field called password which I display in a popup. This is set to password characters (the black blobs). At the end of the script it clears the field - so the password is never stored. This is however compared with one in a script - which I find rather insecure. I really need a way around this - but without deviating significantly from the functionality and benefits it offers. All help would be greatly appreciated.

Best Regards,

Jason V.

[bcooney]

You could use the Relogin script step in a button script to allow an Admin to walk over, click the button, and change the flag. At the end, relogin again and leave the non-admin to relogin.

[robertw236]

:laugh: Thanks for the Welcome LaRetta.

[stockingup]

Thats a great idea. Hadn't actually thought of that. Thanks again for all the help :)

[stockingup]

Just one last question... Whats the best way to validate a user login without making use of the privilige set settings?

By this I mean - If I want a script with a relogin step - if the user enters a password for the higher security clearance account and this is accepted, it automatically sets the field to a different value? Could I check the active privilge set? or should I be doing it by account name? Or any other method?

[stockingup]

Ok... I have been working with this and still can't find a way to do this.

I have two buttons - Activate and Deactivate. If you select Activate it sets a "lock" field to 1, deactivate sets this field to "0". among a variety of other checks I do before hand, when it comes to the Relogin script step, I get it to request a password for an administrative user. the script is not run with full priviliges. As a result, if the account active is not an administrative one, the "lock" field cannot be changed.

However, it comes to a point where I have 2 distinct problems.

1. If I am in an admin account, it will popup anyway, asking for a password. If I hit "Cancel" on the relogin window, it will perform the rest of my script regardless. I have noticed the "getlastmessagechoice" command doesnt work on this popup. how then can I identify the button choice?

2. If I am in a non-admin account, and hit de-activate(for example), it prompts for an admin account. I log in as an admin, it will change the record and then prompt for a login again. What is there to keep the user from hitting cancel, and remaining in admin mode???

[bcooney]

1. Put a dialog before the relogin, confirming that the use wants to enter Admin Mode. Check priv set before unlocking record, if it fails halt script w/o any change.

2. Again, by putting a confirm this action dialog before the relogin you can capture a cancel. Check priv before field change. If they click Cancel at Relogin, they stay in as Admin? I'll have to do up a demo, when I have time.

[stockingup]

Hi bcooney, thanks for the offer to draft up a demo... I seem to have achieved what I was after though. Essentially, I made a popup before the re-login script step, which prompts the user to select whether to continue and login as an admin or cancel. If you hit cancel on the re-login, it simply takes you back to that prompt, wich makes sense generally.

Everything seems to be working fine. Do you think its ok to validate the privilige set names in order to determine whether to proceed or not? I currently have it checking whether the privilige set is [full access], Manager, or LogisticsAdmin. If it is any of those, it will allow the record to be set. However, the script isn't running with admin priviliges. So I guess even if this failed, it still wouldnt let the field be changed due to the privilige set definitions?

Thanks for all the help. Best Regards,

Jason V.