Enabling and disabling menu options on the fly 1

[KornGeek]

I am currently experimenting with enabling and disabling menu options programmatically to limit what options are available to users based on which service level of software they have (standard or deluxe) and which individual permissions they have enabled.

I have figured out how to change which menu bar is displayed based on the service level. I have also tried using code from thread181-77029 to disable functions which are not active based on service level. This works quite well.

My dilemma is around the user-level security permissions. I can check the permissions at start-up and enable or disable accordingly, but I'm not sure how to handle it if their permissions change while using the database.

If an option is enable when it shouldn't be, that is not much of a problem. My forms and reports verify that the user has permission to use them during the OnOpen events. I am mostly concerned with users who are granted permission to do thing, but have the menu options still diabled.

Because I am still experimenting, I am open to any suggestions or comments you may have on this. I appreciate any input I can get.

Thank you.

 

[RickSpr]

I'm not sure I understand where the problem is. The only way the user's permissions could change while the database is running, is if you change them in code. Can't you just adjust the menus at that point?

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[KornGeek]

I'm sorry I didn't make that clear. Because it is a multi-user database, and administrator can change a user's permissions even while the user is logged in to another machine. This isn't a problem when the permissions get disabled because the forms and reports also check permissions when they open. It is only a problem if an administrator grants new permissions, because the menu items would still be disabled.

I hope this makes it more clear.

Thank you.

 

[RickSpr]

Do I understand, then, that your users are all sharing a copy of the database on the network? That carries a danger of corruption, you know--especially if they're using different versions of Access to open it.

If you have a split database with everybody having a copy of the front end on their local machine, the application will run faster and you'll have less chance of corruption. However, it's more complicated to change permissions in that case, because the user whose permissions are changed would have to get a new copy of the front end after the permissions were granted.

Back to your problem. Here is one way to detect the change of permissions: Create a hidden form that is opened at startup (either via the StartupForm property or by your startup code). The form can use a Timer event to check the permissions periodically and adjust the enabled states of the controls. You could either do the adjustment each time the timer fires, or (if you're industrious) you can create a dynamic array of permissions for this user at startup and do a comparison in the Timer event to detect any changes.

Another way: Give the security administrator a Notify function that saves the user name and a timestamp in a table. You still need the Timer hidden form, but it now only has to check for new records in the table (timestamp later than the last time it checked).

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[KornGeek]

Rick,
Thanks for your feedback. I really like your idea of using the Notify function.

Just to clarify, I am using a split database with each user having local front-ends and a shared back-end. The way I update the permissions is by having an "administrator user" using an "Edit User Permissions" form. This form adds or removes the selected user from groups in the mdw file.

The end users themselves are not allowed to edit permissions in the database or directly edit the mdw file. My software handles all of that.

The permissions granted to each group determine what each user is allowed to do or not allowed to do.

I hope this clarifies things a bit.

I think I'm going to play around with a table similar to what you are describing. I already have a hidden form (to keep users from accidentally exiting) and I use a timer to send a heartbeat to a hardware key as part of my copy protection scheme. This should integrate smoothly with my setup.

Thanks again. I appreciate it.

 

[RickSpr]

Ah, I see. It's not the actual object permissions that are changed, only group memberships. So you must be using a shared Workgroup Information File, I assume.

Unfortunately, this is not going to work the way you envision. Access obtains the user's SID and the SIDs of all groups the user belongs to when it builds the Workspace object at logon time. Changes in the workgroup file after that point will not be reflected in the workspace. You'd have to create a new default workspace in order to see the new group memberships, and you can only do that is by exiting Access and restarting it.

Changes to object permissions are checked when the object is opened. If you modified the user's direct permissions, those would take effect in the currently open database, but won't get reloaded until the next time the object is opened. Thus, if you have a form open, for example, and the administrator added more permissions for you on the form, you still wouldn't obtain those permissions on the open copy of the form. You'd have to close it and reopen it.

I had to do some experimenting to find this out. I had been wondering whether Access captured the user and group SIDs when it built the workspace, or whether it looked them up each time an object was opened. Now I know, but unfortunately it works against what you want to do.

Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein

 

[KornGeek]

Rick,
Thanks for the feedback. There is obviously much more that I still have to learn about Access security, but I've come a long way since discovering Tek-Tips (and JeremyNYC's website).

The way I'm getting this to work is that I have groups set up to signify what a user is allowed to do (for instance, one group to add new user profiles, another to delete user profiles, another to edit user profiles, yet another to run reports, etc). As each form or report is opened, I simply check to see if the current user is a member of the required group. I could also check group membership during a timer event to turn menu options on or off as you described.

So, in a nutshell, we are using a shared mdw file. Users must be joined to this mdw to open the database. End users do not have the ability to edit permissions on the database or edit this mdw file directly (they don't have the password to the only administrator account, and that account is unable to open the database). The database provides a utility to allow "administrator" users to add people to or remove people from pre-defined groups. The membership in these groups determines what a user is or is not allowed to do. Forms and reports verify a user's permissions (by checking group membership) before opening, and provide an appropriate error message and cancel opening if the user is not authorized.

While this has the drawback of being a little bit less secure than using Access permissions directly, it provides the functionality that I was asked to implement. For our set up, it seems to be the best approach.