Limiting access right base on login name?

[SF]

Hi,

I am looking for a sample or guideline for limiting right of user in
accessing to some forms and reports based on their login name. eg I want to
limit ordinary users to access to some features or forms that has been
designed for Administrator use.

SF

 

[Rick Brandt]

I am looking for a sample or guideline for limiting right of user in
accessing to some forms and reports based on their login name. eg I
want to limit ordinary users to access to some features or forms that
has been designed for Administrator use.

Depends on what you mean by "limiting". If you want to provide "guidance" to
users who are largely cooperative and ignorant of Access then what you are
describing is very simple to set up. If you need hard barriers against
knowledgable people who might maliciously attempt to get around your rules then
forget about the idea now.

I use server databases and control the "real security" on the server, but use
the guidance strategy on the front end mostly to avoid unfriendly server error
messages. What I do is use two tables. One which maps the network login name
to the person's actual name (this is used to display and store actual names as
required). Then a second table matches logins to permission codes. These are
just short strings that I make up for any given purpose.

A custom function Permission() is used to check for a persons permission in a
given scenario. It simply looks in the second table to see if the current login
has the appropriate permission code and returns True when they have it and False
when they do not. So to "secure" a form I can use the following in its Open
event...

If Not Permission("someCode") Then
MsgBox "Not Authorized"
Cancel = True
End If

The same system can make certain form read only, or whatever you need. I also
give myself the permission code "X" which provides universal access.

Now...in an app using an MDB for the data anyone can backdoor the permissions
table and give themselves any code they want which is why my system only has
some teeth by using a server table that the user cannot make edits in. All you
can do in an MDB is hide or otherwise obscure things and of course apply User
Level Security to remove edit rights to the table. Of course if you are going
to do that then you don't need the whole custom system described above in the
first place. Also is the fact the ULS can be hacked by the willing and is no
longer supported in the new 2007 file format.

 

[Pat Hartman]

My approach is similar to Rick's but I go one step further and use my custom
security settings to control what shows on the menus. I keep a server-side
copy of [Switchboard Items] which I have modified to include additional
columns. I open the application to a hidden form that runs a query that
creates a local version of [Switchboard Items] that contains only what the
user is authorized to work with. The hidden form then opens the
switchboard.