Thx @bastanu i willHave a look at my free utility here:
FBA Custom Access Levels - ForestByteApps
ForestByteApps - A place for Microsoft Access code samples and utilities to make your life easier. Free Microsoft Access tools and sample VBA codeforestbyte.com
Cheers,
Thnx @The_Doc_Man for your detailed replyThere 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.
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?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.
Yeah @bastanu i downloaded your file but zip file shows errors unable to open database fileHave 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,
thx this file is workingStrange, I had no problems with it, but here it is, let me know if it works.
Cheers,