Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Different Switchboard for users 3

Status
Not open for further replies.

rexrivas

Technical User
Apr 19, 2004
20
US
i have a switchboard, with several forms and no buttons for reports. i would like to have buttons for reports for certain users only. Can i have buttons appears based on specific users?
 
You can have just about anything you want as long as you design the application correctly. You comment implies you have the users log on using some type of login that would identify each user. If you are using Access security then you can use DAO code to get information about the user; such as their username and group permissions. That's the way I would work it. Now you also imply that your switchboard is non-standard from the table driven switchboard form provided with Access. That may be more difficult to integrate with this concept.

A simple example using Access security and DAO:
If CurrentUser = "JohnJones" Then
' Do this
ElseIf UserIsMemberOfGroup("Admins") Then
' Do this instead
End If



---------------------
scking@arinc.com
---------------------
 
I have this same situation in many of my databases. Like the response above, once you have established their log on id, simply have a 'Select Case' stmt in the Switchboard's Form_Load event. Suppose a command button named 'cmdReports' opens another form to allow three users to run your reports and suppose those three employees have numbers X0078, X0080 and X0095. Then you might do something like:

Private Sub Form_Load()
Select case txtlogonid 'or wherever their log on id is
Case "X0078", "X0080", "X0095"
cmdReport.Visible = True
Case Else
cmdReport.Visible = False
End Select
End Sub

Then, those three users will have a Reports command button available (visible)to them to click, if they want to run reports.

Hope this helps, too.
 
Heres another way.
create a new module and paste this in:-
=============================
Code:
Private Declare Function apiGetUserName Lib "advapi32.dll" Alias _
    "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long

Function fOSUserName() As String
' Returns the network login name
Dim lngLen As Long, lngX As Long
Dim strUserName As String
    strUserName = String$(254, 0)
    lngLen = 255
    lngX = apiGetUserName(strUserName, lngLen)
    If lngX <> 0 Then
        fOSUserName = Left$(strUserName, lngLen - 1)
    Else
        fOSUserName = ""
    End If
End Function
=================================================

save it as something like LoginId
now on your form create a new unbound text field and set its default value to
fOSUserName()

the next step is to create individual forms for your users.
name them user1PersonalForm etc.
where user1 is the users actual login ID.
in the click event of the button have
DoCmd.OpenForm fOSUserName()& "PersonalForm"

Regards

Alex
*Thanks to Scotian for helping with this originally*

“It is a mistake to think you can solve any major problems just with potatoes.”
Douglas Adams
 
I can't imagine having to create a separate form for each user would be a viable solution. That means you have to constantly update the code whenever anyone comes or leaves the company. It would work for maybe 2/3 users in a very stable environment. You should always manage permissions using a group and assigning individual users group permissions.

Example:
GroupA is superusers and has full permissions
GroupB is limited users and can't change design
GroupC can only read data

John is member of GroupA
Joe is member of GroupB and GroupC

Sub Form_Open
If UserIsMemberOfGroup("GroupA") Then
' Allow access to the write data form
Me.btnWriteData.Enabled = True
Else
Me.btnWriteData.Enabled = False
End If
End Sub






---------------------
scking@arinc.com
---------------------
 
Use the logins to make the buttons visible or not.

Using Metal Boys example... in the oncurrent event of your switchboard...

If fOSUserName() = "Your User" Then
Me![Your Command Button].Visible = True
Else
Me![Your Command Button].Visible = False
End If

Bill
 
I think MetalBoy has the right idea in getting the Network login ID. I do that same for my databases. If the Network administrators are worth anything, why not use their security to establish who is using the database.

I don't create individual forms for each user. I have one form (and table) that has a record of all users, including there loging ID.

When I start up my db. The first form to open has an unbound field which gets the login ID using metalBoys ID. From that, a second form opens based on a query that looks for the login ID in form 1. This will bring up the user that just logged in and all of his details. Hide this form (Form.visible = False)

Now when you open a switchboard or any other form with fields or data that you don't want the user to see, just refer to what ever data is in the hidden form and give him the required access on the form. This is by far the most flexible way of providing multi level access to forms. You have comlpete control over what you want peolpe to see.

Very generalised, but I hope it rounds out the useful posts from above

Good luck

Jedel
 
I have been happily using the Get Login Name API for a couple of years now. On Friday however, we had a batch of PC's installed loaded with XP and the API no longer works. It is the exact same API shown higher up in this thread. I have refreshed the reference links, which solved a number of other problems, but not this one. Does anyone have any ideas how to solve this?
 
I let the user decide which form they want opened at startup. When I initially install the FE on a users machine, the Main form is displayed. From the main form the user can access all other forms. However, as the user becomes more knowledgeable about the system and gets into a routine of how they use the system they find that there is one form that the usually go to. For example, 95% of the time a set of user's always go from the main form to the report criteria form. Consequently, the user can specify that when they open the db, the report criteria form is opened rather than the main form (thus bypassing the main form). Likewise, another user may always to the the form that allows them to edit the data. Consequently, they would pick this form to be opened at startup rather than the main.
 
FancyPrairie, just out of curiosity (yeah, it killed my cat too) how do you allow the user to set the form?

Rod
 
Hmmm
Regardless of your strategy, one component to consider is to set a global boolean variable which would probably simplify your code.

During the login process set the boolean to true or false depending on admin access. Then instead of have numerous IF or CASE statments, the visible state or the locked state some of the commands / fields / forms can be set by using the boolean variable.

Select case YourLoginVariable
Case "MEE", "MYSELF", "EYE"
booAdmin = True
Case Else
booAdmin = False
End Select

Where booAdmin is a global boolean variable

... later
Me.YourCommandButton.Visible = booAdmin
Me.YourField.Enabled = booAdmin
Me.YourSubForm.Visible = booAdmin

etc...

Not much overhead for a boolean variable. You could expand on the idea I guess by adding other global boolean variables for special tasks for the super users. Or add a user to the admin group so they can access the admin menus while you are on vacation. Heck, you can even create a back door for support and re-set the booAdmin variable when trouble shooting a user's problem.

Richard








 
I created a table (i.e. tblUserProfile) that contains the user's name, phone number, office location, access login name (or you could store their nt user name), and the form that they want opened at startup (and any other info you want to know about the user). (This helps when I need to get in touch with a user or need to know where they are located, etc). I then created a form (frmUserProfile) that contains all of this information. Then, at startup, I open the table to determine which form they want opened. If their name does not exist in the table, then I popup frmUserProfile (add record mode) and have them enter the information about themselves (including which form they want opened at startup). (Upon closing the form, the form they selected will then be opened.)

Note that from the main menu the user can open (via the menubar) frmUserProfile to change whatever they want anytime they want.

To allow the user to select which form they want, I created a combobox that lists all of the forms in the database (actually I have another table that I use to define information about each database. Therefore, I can limit which forms I want the user to choose from). Anyway, the following query will list all of the forms in the database:

SELECT MSysObjects.Name FROM MSysObjects WHERE (((MSysObjects.Type) = -32768)) ORDER BY MSysObjects.Name;

 
One thing I forgot to mention, I also include the name of the database as one of the fields within the table tblUserProfile. That way I can use the same form, table, code etc (resides in my library) for each database I put together.
 
Thanks for the info, seems you have negated the necessity of a menu or switchboard. I'll have to try it and if it works well, I may use the structure in a future database.


Regards
Rod
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top