Cause record NAV buttons to require a password to be active

[Repent]

I have a form with several fields that a user fills out. On the form
are record NAV buttons. We don't want users to be able to go back to
a previous record to edit or make changes but I'd like the supervisor
to be able to in case the user makes a mistake. Is there code to make
a password dialog box popup when a user clicks on any of the NAV
buttons and if the correct password is typed in, the NAV buttons then
become active?

 

[Dorian]

You want to build a system that prevents people from correcting mistakes?
I urge you to rethink what you are designing, it sounds quite ridiculous.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".

 

[Linq Adams via AccessMonster.com]

On the contrary, Dorian, locking a record after it has been saved is done
every day, for a myriad of reasons! You wouldn't want to do it before the
record is saved, of course, in case the user made a mistake, but locking it
after is a reasonable requirement.

The OP in this case is smarter than the person we see all too often who posts
wanting to lock records without giving thought to how corrections will be
made.

How complicated this is depends on whether you want a single, hardwired
password or whether you want to have changeable passwords. In it's simplest
form, using a single, hardwired password, you could use this, code along with
a button to 'unlock' the record for editing:

Private Sub Form_Current()
Me.AllowEdits = False
End Sub

Private Sub UnlockRecordButton_Click()
Dim PW as String

PW = InputBox("Enter Password to Edit Record")

If PW = "Me boss" Then
Me.AllowEdits = True
End If
End Sub

For multiple and/or changeable passwords you'd have to have a separate table
to hold the passwords then check the entered password against possible
passwords in the table.

 

[Klatuu]

There is a way it can be done without requiring a password.
Create a table with two fields. One with the Windows Login ID of all system
users. The other a Boolean field where True = Can Edit existing records and
False = Can only enter new records.

Then use the Load event of the form to set the Allow Edits property of the
form as desired.

First, to get the user id, paste this code into a standard module by itself.
Be sure you do not name the module the same name as the function.

Private Declare Function GetUserNameA Lib "Advapi32" (ByVal strN As String,
ByRef intN As Long) As Long
Public Function GetUserID()

Dim Buffer As String * 20
Dim Length As Long
Dim lngresult As Long, userid As String

Length = 20

lngresult = GetUserNameA(Buffer, Length)
If lngresult <> 0 Then
userid = Left(Buffer, Length - 1)
Else
userid = "xxxxxxx"
End If
GetUserID = UCase(userid)

End Function

**************************************

Now in the Load Event:

Me.AllowEdits = Nz(DLookup("[CanEdit]", "[tblUsers]", "[LogIn] = '" &
GetUserID & "'"), False)

 

[Ron2006]

Be aware of the following:

The solution that Dave gives above will work but with the following
limitation:
supervisor john xxxx will only be able to do the edits from his own
desktop when he is logged in to the network as himself. A backup
supervisor, for instance, would NOT be able to enter the application
and do the changes for John from his own machine or while logged in as
himself.

If John's computer goes down he will NOT be able to make changes from
a different computer UNLESS he is logged into the network as himself.

In a few of my applications I have a separate user table with a flag
indicating that individuals have or do not have supervisor update
authority. That way anybody on the team can be desiginated as the
point of contact for types of changes. For that matter, I have user
access, Report access, and supervisor access - each with more
authority and access to more menus and more change capabilities,
including the ability to change the access aspects in the user table
from their own authority down to less authority. for instance: the
Report access can assign that ability to other individuals but cannot
assign superviser access.

I do however also keep track of who is logged into the application by
network ID for audit change purposes.

Ron
Ron

 

[Klatuu]

Your points are well taken regarding who is logged on.
As to a substitute, an administrator could change their flag to True for the
duration. That is the reason I do it that way.

If a person is using another person's computer, they should not be. Most
companies see that as a security violation. To tighten it up, there is an
API that will give you the name of the computer you are on. You can ensure a
the right person is on the right computer.

What I did find interesting is that after you valid comments, you make this
statement:

I do however also keep track of who is logged into the application by
network ID for audit change purposes.


It sort of blows away your whole argument.

 

[Linq Adams via AccessMonster.com]

I gave an answer in response to the OP's wanting to use a password, but I
usually use a much simpler method, having the click event of a label on the
form 'unlock' the record to editing. Most users, in my experience, aren't
aware that labels can be clicked on, and a supervisor can gain access from
any computer. They simply ask the PC's owner to look away and click, it's
done. Less apt to be observed than entering a password.

Private Sub Form_Current()
Me.AllowEdits = False
End Sub

Private Sub InnocentLookingLabel _Click()
Me.AllowEdits = True
End Sub

 

[Ron2006]

Yes and No.

The situation under which this has come into play is when the actual
owner of the records is out sick or on vacation and therefore the
assigned backup person must perform certain necessary work for the
owner. In this case since the records that are selected for review are
keyed by the login in person, the backup person will login to the
application under the owners name but on their own computer. The
double posting of login and network login then act as a reminder that
the owner was on vacation in that time frame and the backup person was
performing the action. The actions in this application require
multiple timed/spaced actions for an account spaced over a large
timeframe thus requireing backup operator procedures.

The following sentence: "If John's computer goes down he will NOT be
able to make changes from
a different computer UNLESS he is logged into the network as himself.
" was a statement of the implication of using the network id not a
suggestion. We do not login to the network under our own ID on someone
else's computer.

Ron