Cross reference CurrentUser() against a table of names

[Ron]

I have a CurrentUser() value setup in an Unbound field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1 & 2
are hidden; etc.
Now I know how to hide buttons using the Visible property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script (and
having to remember to change names in that Array if people
leave), I would rather it cross reference the tables where
the names are stored using that Unbound field [CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their values
are used elsewhere). We'll call the tables [Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron

 

[TC]

Say you defined a "user level" value for each user, in a table of user names
& associated user levels.

The OnLoad event of a form could use the DLookup() function to retrieve the
user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup ("UserLevel", "UserTable", "UserName=""" &
currentuser() & """")

Then you could use the retrieved user level value to hide or unhide controls
etc.

Just two points:

- This kind of "home grown" security would be trivial for a knowledgable
user to break. You could do it safer using Access user-level security, but
that has a waaaaaay steeper learning curve than you might want to have right
now!

- It is normally considered better practice to >disable< inapplicable
controls, not make them invisible. See the Enabled property in online help.

HTH,
TC

 

[MacDermott]

One more aside here:
Access provides the built-in function CurrentUser() which always returns
the value "admin" if Access security is not implemented.
Therefore, it would be a good idea to give your custom function a
different name, to avoid confusion.

HTH
- Turtle

Say you defined a "user level" value for each user, in a table of user names
& associated user levels.

The OnLoad event of a form could use the DLookup() function to retrieve the
user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup ("UserLevel", "UserTable", "UserName=""" &
currentuser() & """")

Then you could use the retrieved user level value to hide or unhide controls
etc.

Just two points:

- This kind of "home grown" security would be trivial for a knowledgable
user to break. You could do it safer using Access user-level security, but
that has a waaaaaay steeper learning curve than you might want to have right
now!

- It is normally considered better practice to >disable< inapplicable
controls, not make them invisible. See the Enabled property in online help.

HTH,
TC

I have a CurrentUser() value setup in an Unbound field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1 & 2
are hidden; etc.
Now I know how to hide buttons using the Visible property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script (and
having to remember to change names in that Array if people
leave), I would rather it cross reference the tables where
the names are stored using that Unbound field [CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their values
are used elsewhere). We'll call the tables [Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron

 

[Ron]

Thanks for the input. I do have an Access Security
Workgroup and user levels defined, but it does make some
sense to use a sort of defined user level in the existing
tables at least for the lookup.
How hard would it be if it worked off of the Access
security group?

Ron

-----Original Message-----
One more aside here:
Access provides the built-in function CurrentUser() which always returns
the value "admin" if Access security is not implemented.
Therefore, it would be a good idea to give your custom function a
different name, to avoid confusion.

HTH
- Turtle

Say you defined a "user level" value for each user, in

a table of user
names

& associated user levels.

The OnLoad event of a form could use the DLookup()

function to retrieve
the

user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup ("UserLevel", "UserTable", "UserName=""" &
currentuser() & """")

Then you could use the retrieved user level value to

hide or unhide
controls

etc.

Just two points:

- This kind of "home grown" security would be trivial for a knowledgable
user to break. You could do it safer using Access user- level security, but
that has a waaaaaay steeper learning curve than you

might want to have
right

now!

- It is normally considered better practice to disable< inapplicable
controls, not make them invisible. See the Enabled

property in online
help.

HTH,
TC

I have a CurrentUser() value setup in an Unbound field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1 & 2
are hidden; etc.
Now I know how to hide buttons using the Visible property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script (and
having to remember to change names in that Array if people
leave), I would rather it cross reference the tables where
the names are stored using that Unbound field [CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their values
are used elsewhere). We'll call the tables [Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron

.

 

[MacDermott]

I'm afraid it escapes me entirely what is to be gained by creating a system
which duplicates the existing Access Security functionality.
I'd suggest you read up on Access security Users and Groups.

HTH
- Turtle

Thanks for the input. I do have an Access Security
Workgroup and user levels defined, but it does make some
sense to use a sort of defined user level in the existing
tables at least for the lookup.
How hard would it be if it worked off of the Access
security group?

Ron

-----Original Message-----
One more aside here:
Access provides the built-in function CurrentUser() which always returns
the value "admin" if Access security is not implemented.
Therefore, it would be a good idea to give your custom function a
different name, to avoid confusion.

HTH
- Turtle

Say you defined a "user level" value for each user, in

a table of user
names

& associated user levels.

The OnLoad event of a form could use the DLookup()

function to retrieve
the

user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup ("UserLevel", "UserTable", "UserName=""" &
currentuser() & """")

Then you could use the retrieved user level value to

hide or unhide
controls

etc.

Just two points:

- This kind of "home grown" security would be trivial for a knowledgable
user to break. You could do it safer using Access user- level security, but
that has a waaaaaay steeper learning curve than you

might want to have
right

now!

- It is normally considered better practice to disable< inapplicable
controls, not make them invisible. See the Enabled

property in online
help.

HTH,
TC


I have a CurrentUser() value setup in an Unbound field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1 & 2
are hidden; etc.
Now I know how to hide buttons using the Visible property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script (and
having to remember to change names in that Array if people
leave), I would rather it cross reference the tables where
the names are stored using that Unbound field [CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their values
are used elsewhere). We'll call the tables [Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron

.

 

[TC]

But he is not necessarily trying to replicate Access security (which I agree
is a pointless exercise). He might just be trying to meet this need: "I have
several users who perform different tasks. It would be useful if the screens
could be tailored to the current user's need; for example, by having
irrelevant controls disabled."

In that case, it would make lots of sense to avoid the complications of
user-level security, & code-up something seperately. It would just need a
single table to hold the settings, & a maintenance form to alter them. This
would not be trying to impose "security", as such, & it would be waaaaay
easier than implementing proper security, properly. All he'd have to do is
add some users to the default workgroup file, so CurrentUser() returned
something useful.

Cheers,
TC

I'm afraid it escapes me entirely what is to be gained by creating a system
which duplicates the existing Access Security functionality.
I'd suggest you read up on Access security Users and Groups.

HTH
- Turtle

Thanks for the input. I do have an Access Security
Workgroup and user levels defined, but it does make some
sense to use a sort of defined user level in the existing
tables at least for the lookup.
How hard would it be if it worked off of the Access
security group?

Ron

-----Original Message-----
One more aside here:
Access provides the built-in function CurrentUser() which always returns
the value "admin" if Access security is not implemented.
Therefore, it would be a good idea to give your custom function a
different name, to avoid confusion.

HTH
- Turtle

Say you defined a "user level" value for each user, in a table of user
names
& associated user levels.

The OnLoad event of a form could use the DLookup() function to retrieve
the
user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup

("UserLevel", "UserTable", "UserName=""" &

currentuser() & """")

Then you could use the retrieved user level value to hide or unhide
controls
etc.

Just two points:

- This kind of "home grown" security would be trivial for a knowledgable
user to break. You could do it safer using Access user- level security, but
that has a waaaaaay steeper learning curve than you might want to have
right
now!

- It is normally considered better practice to
disable< inapplicable
controls, not make them invisible. See the Enabled property in online
help.

HTH,
TC


I have a CurrentUser() value setup in an Unbound field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1 & 2
are hidden; etc.
Now I know how to hide buttons using the Visible property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script (and
having to remember to change names in that Array if people
leave), I would rather it cross reference the tables where
the names are stored using that Unbound field [CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their values
are used elsewhere). We'll call the tables [Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron





.

 

[MacDermott]

If, as he says, he does have "an Access Security Workgroup and user levels
defined", why not use that existing information, instead of setting up a
redundant and less secure table?

- Turtle

But he is not necessarily trying to replicate Access security (which I agree
is a pointless exercise). He might just be trying to meet this need: "I have
several users who perform different tasks. It would be useful if the screens
could be tailored to the current user's need; for example, by having
irrelevant controls disabled."

In that case, it would make lots of sense to avoid the complications of
user-level security, & code-up something seperately. It would just need a
single table to hold the settings, & a maintenance form to alter them. This
would not be trying to impose "security", as such, & it would be waaaaay
easier than implementing proper security, properly. All he'd have to do is
add some users to the default workgroup file, so CurrentUser() returned
something useful.

Cheers,
TC

I'm afraid it escapes me entirely what is to be gained by creating a system
which duplicates the existing Access Security functionality.
I'd suggest you read up on Access security Users and Groups.

HTH
- Turtle

Thanks for the input. I do have an Access Security
Workgroup and user levels defined, but it does make some
sense to use a sort of defined user level in the existing
tables at least for the lookup.
How hard would it be if it worked off of the Access
security group?

Ron

-----Original Message-----
One more aside here:
Access provides the built-in function CurrentUser()
which always returns
the value "admin" if Access security is not implemented.
Therefore, it would be a good idea to give your
custom function a
different name, to avoid confusion.

HTH
- Turtle

Say you defined a "user level" value for each user, in
a table of user
names
& associated user levels.

The OnLoad event of a form could use the DLookup()
function to retrieve
the
user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup
("UserLevel", "UserTable", "UserName=""" &
currentuser() & """")

Then you could use the retrieved user level value to
hide or unhide
controls
etc.

Just two points:

- This kind of "home grown" security would be trivial
for a knowledgable
user to break. You could do it safer using Access user-
level security, but
that has a waaaaaay steeper learning curve than you
might want to have
right
now!

- It is normally considered better practice to
disable< inapplicable
controls, not make them invisible. See the Enabled
property in online
help.

HTH,
TC


message
I have a CurrentUser() value setup in an Unbound
field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a
hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form
according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1
& 2
are hidden; etc.
Now I know how to hide buttons using the Visible
property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script
(and
having to remember to change names in that Array if
people
leave), I would rather it cross reference the tables
where
the names are stored using that Unbound field
[CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their
values
are used elsewhere). We'll call the tables
[Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form
to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron





.

 

[TC]

Yes, I agree that he refers to "user levels". But his first description of
his need, was that he wanted to restrict access to certain buttons based on
"who is logged in". And his examples said, "if User 1 is logged-in", "if
User 2 is logged in", etc. So despite his reference to "user levels" later
in the thread, I am not convinced that he has >actually< set up any formal
access permission levels, at all! I think he has just added more users to
the default workgroup file.

Turtle, I agree entirely that it is a waste of time trying to implement a
"home grown" security scheme instead of using Access'es. We have no argument
there. But I'm still not convinced that he actually >wants< security (in the
sense that you & I understand that word in an Access context), or that it is
necessary to go down that complex path, to meet his needs efficiently.

But only he can say! Ron, are you there? Do you have any comment? Earth to
Ron! Earth to Ron!

Cheers,
TC

If, as he says, he does have "an Access Security Workgroup and user levels
defined", why not use that existing information, instead of setting up a
redundant and less secure table?

- Turtle

But he is not necessarily trying to replicate Access security (which I agree
is a pointless exercise). He might just be trying to meet this need: "I have
several users who perform different tasks. It would be useful if the screens
could be tailored to the current user's need; for example, by having
irrelevant controls disabled."

In that case, it would make lots of sense to avoid the complications of
user-level security, & code-up something seperately. It would just need a
single table to hold the settings, & a maintenance form to alter them. This
would not be trying to impose "security", as such, & it would be waaaaay
easier than implementing proper security, properly. All he'd have to do is
add some users to the default workgroup file, so CurrentUser() returned
something useful.

Cheers,
TC

I'm afraid it escapes me entirely what is to be gained by creating a system
which duplicates the existing Access Security functionality.
I'd suggest you read up on Access security Users and Groups.

HTH
- Turtle

Thanks for the input. I do have an Access Security
Workgroup and user levels defined, but it does make some
sense to use a sort of defined user level in the existing
tables at least for the lookup.
How hard would it be if it worked off of the Access
security group?

Ron

-----Original Message-----
One more aside here:
Access provides the built-in function CurrentUser()
which always returns
the value "admin" if Access security is not implemented.
Therefore, it would be a good idea to give your
custom function a
different name, to avoid confusion.

HTH
- Turtle

Say you defined a "user level" value for each user, in
a table of user
names
& associated user levels.

The OnLoad event of a form could use the DLookup()
function to retrieve
the
user level for the current user:

dim sUserLevel as string
sUserLevel = DLookup
("UserLevel", "UserTable", "UserName=""" &
currentuser() & """")

Then you could use the retrieved user level value to
hide or unhide
controls
etc.

Just two points:

- This kind of "home grown" security would be trivial
for a knowledgable
user to break. You could do it safer using Access user-
level security, but
that has a waaaaaay steeper learning curve than you
might want to have
right
now!

- It is normally considered better practice to
disable< inapplicable
controls, not make them invisible. See the Enabled
property in online
help.

HTH,
TC


message
I have a CurrentUser() value setup in an Unbound
field on
a form called [Startup] because I want to know who's
logged in.
Now here's what I would like to do but I'm having a
hard
time figuring out the best way to do it.
I would like to hide certain buttons on the Form
according
to who's logged in at the time.
i.e. If User 1 is logged in then he/she wouldn't see
buttons 2 & 3; if User 2 is logged in then buttons 1
& 2
are hidden; etc.
Now I know how to hide buttons using the Visible
property
in VB, but instead of adding users to probably an
If..Then..Else in some sort of an Array in the script
(and
having to remember to change names in that Array if
people
leave), I would rather it cross reference the tables
where
the names are stored using that Unbound field
[CurrentUser]
on the [Startup] form with the CurrentUser() function
attached to that field.
I have a couple of user tables already setup (their
values
are used elsewhere). We'll call the tables
[Designers] &
[Developers]
I'm using the On_Load property of the [Startup] form
to
develop the script.
Is there a way to do this?
Any help would be appreciated.

Thanks!

Ron