User's Role

ZEEq

Member
Local time
Tomorrow, 00:14
Joined
Sep 26, 2022
Messages
93
Hello to all Respectable Members
is it possible to assign roles to users in access database and put restrictions on their activity ?
Limit their access to to certain forms and reports etc
if someone could share a sample
 
Look at the first thread in Similar threads at the bottom of this thread.
 
thx @Gasman yes i read that thread i also searched other threads on this forum and saw @Pat Hartman switchboard please tell me switchboard is the way to do this?
 
Switchboard is the way I did it.
I see little point of showing a user something, but when they click on it, they get an error message that they are not authorised to use it. Then again, that is just me.
If you use Pat's method you should not go wrong.
 
There are many ways to do role-oriented actions. The FIRST thing you must do is to decide how you wish to restrict users based on their roles.

Does this restriction involve which RECORDS they can see? Or does it depend on which FIELDS within a record? Does it involve which FUNCTIONS they can use? Does it involve hiding certain FORMS? All of these and more are possible, but first you must decide the effect you wish to achieve. The more you want to do, the more complex it will get, but ALL of these and more can be done as a matter of user role recognition.

The starting point is that you must be able to identify the user so that you can somehow determine that user's role. User identification is therefore part of the problem. Again, we have many ways to accomplish that result. But YOU must decide at least part of that by looking at your environment to see which of the many kinds of user identification COULD be used. For instance, are you in a restrictive domain environment? Are you in a rather wide-open network where logins are managed on individual machines? Something else?

This IS a valid place to ask, but to give you a good answer we need to know (a) your environment and (b) the real goal of your role-based restrictions. And (c) if this can happen: Two users have the same roles but because of different responsibilities will have differentiated abilities. E.g. two account representatives with different groups of accounts; same jobs but for different customers. That is ALSO possible and needs to be folded into any solution.

Now that you know what you COULD ask, decide what you really need. We can talk about it.
 
There are many ways to do role-oriented actions. The FIRST thing you must do is to decide how you wish to restrict users based on their roles.

Does this restriction involve which RECORDS they can see? Or does it depend on which FIELDS within a record? Does it involve which FUNCTIONS they can use? Does it involve hiding certain FORMS? All of these and more are possible, but first you must decide the effect you wish to achieve. The more you want to do, the more complex it will get, but ALL of these and more can be done as a matter of user role recognition.

The starting point is that you must be able to identify the user so that you can somehow determine that user's role. User identification is therefore part of the problem. Again, we have many ways to accomplish that result. But YOU must decide at least part of that by looking at your environment to see which of the many kinds of user identification COULD be used. For instance, are you in a restrictive domain environment? Are you in a rather wide-open network where logins are managed on individual machines? Something else?

This IS a valid place to ask, but to give you a good answer we need to know (a) your environment and (b) the real goal of your role-based restrictions. And (c) if this can happen: Two users have the same roles but because of different responsibilities will have differentiated abilities. E.g. two account representatives with different groups of accounts; same jobs but for different customers. That is ALSO possible and needs to be folded into any solution.

Now that you know what you COULD ask, decide what you really need. We can talk about it.
Thnx @The_Doc_Man for your detailed reply
My goal is after completion of my database project i will split that database and distribute the frontend to 4 accountants only they have access to the computers
I just want to learn how can i restrict their access e.g who can add and edit records
Give them access to selective forms something like that right now that's in my mind may be as i progress with database i may think of some other restrictions as well
 
On my phone so can’t check solutions provided but to simplify management of users I create groups - admin,hr,sales, marketing, production, whatever. These groups have rights as to what they can see and do. I then assign users to one or more groups.
 
I'm assuming that is the sample you looked at. It is based on the concept of the Access switchboard and the table is basically Switchboard Items with some added fields. But, this version uses a subform rather than hard-coded buttons. The advantage is that you can use the security to control what shows on the switchboard. If you don't have the permission to view a form, it does not appear in the switchboard you see. Try the three versions of my login shown on the form. The values in red give you all permissions but the other two options restrict what you can see and what you can do.

The example controls security at the form level. If you need to control data for a form, you would need to use ranges when checking the security. So level 5-7 could update the form but you would have to validate the level again for each field you want to control at anything higher than 5.
yes @Pat Hartman i am trying to figure out your concept plz tell me is it possible to use this concept on Forms instead of switch board? and also what steps do i need to follow?
 
Have you had a chance to download and look at my utility? You need to import all objects (make sure you turn the View system objects on as there are a few custom system tables prefixed with "usys"). It basically stores the "access" rules in a shared system table to you can add\edit\remove rules by simply editing records in a table instead of changing VBA code. On each form you simply add one line to the Open event of the form and the access rules will apply regardless of how you opened the form (from a swithboard, directly from the navigation pane or from another form). You can edit the form's properties (such as allow edits, allow adding or deleting for both the main form and any subforms) and the individual controls - the Visible, Locked and Enabled propterties.

Cheers,
 
Have you had a chance to download and look at my utility? You need to import all objects (make sure you turn the View system objects on as there are a few custom system tables prefixed with "usys"). It basically stores the "access" rules in a shared system table to you can add\edit\remove rules by simply editing records in a table instead of changing VBA code. On each form you simply add one line to the Open event of the form and the access rules will apply regardless of how you opened the form (from a swithboard, directly from the navigation pane or from another form). You can edit the form's properties (such as allow edits, allow adding or deleting for both the main form and any subforms) and the individual controls - the Visible, Locked and Enabled propterties.

Cheers,
Yeah @bastanu i downloaded your file but zip file shows errors unable to open database file
 

Users who are viewing this thread

Back
Top Bottom