Object Accessibility Permission based on User Roles

[smtazulislam]

I would like to redesign an Object Accessibility Permission system based on User Roles. My current design is complicated and difficult for some administrators to understand. I would appreciate your advice on simplifying and improving it.

Object Name selection like

The system involves mapping LtblUserObjectType to ObjectType, with the following structure:
Form: Displays all form names
Select Form: Expands to show all ObjectTypes within the selected form (e.g., TextBox, ComboBox, CommandButton, TabControl, TabPage, SubForm, ListBox, Frame, CheckBox, Label)

Detailed attached excel file.
Could you provide suggestions on how to improve the clarity and functionality of this system?

 

[The_Doc_Man]

The first goal in designing a User-Role-Ability system is defining two major things. First, what the roles will be (including a statement of duties of anyone having that role). Second, a statement of abilities of the given role. Those two statements sound similar, and in fact they DO intertwine. However, one is job-related; the other is application-related or implementation-related. A huge part of the problem is determining the differences between two roles based on facets from both statements - duties and abilities.

Questions you should ask along the way include: how much do related roles overlap? I.e. If you have a System Admin and a System Supervisor, what is the business function of each, and what parts of the description delineate those roles (from both viewpoints)?

You also suggest that it is "difficult for some administrators to understand." I'm asking this question from the outside because I don't know your business and this is a crucial part of your question: What is there about your system that requires them to understand ANYTHING? It is a rhetorical question because the obvious answer is that the question implies that the roles and their abilities must not be well understood.

Which leads to the question: What issues in your chosen roles are not understood by those who live and work in that environment and why? Is there a disconnect between your implemented roles vs. the corporate job descriptions? As many roles as you had, I can't imagine you have a tiny business, which means you should have at least SOME formality in job assignments. Do your roles not align with actual job descriptions? Or is your company organized such that descriptions are not commonly discussed?

Stated another way, your question suggests a disconnect between your system and your users. Find that disconnect first. It will guide you to the correct solution. Which oddly enough might represent a need to formalize job descriptions rather than (or perhaps in parallel with) making changes to your code.

 

[mdlueck]

In a Client/Server application I developed with an Access FE, then on the SQL BE DB, it was running on a single shared DB account.

The Access FE obtained who the account was of the Windows login, authenticated by matching username.

Additionally, those login ID accounts had permissions within the application. Ability to Insert records, ability to change records, ability to delete records, and so on.

The VBA code would check before it allowed (enabled the button perhaps) if that user was allowed to perform the specific operation.

The application had few enough permissions that I was able to pack them into a binary number stored has HEX. Permission mask was calculated by reading the user ID permissions check boxes (as binary bits), then storing in the DB as a HEX value. Looking up an account permissions did the reverse.... read the HEX number, converted to binary, then mapped each significant bit to the permission on/off.

Worked very well / solid solution.

I am thankful,

 

[The_Doc_Man]

As to implementation of my app that had the most to do with role-based security, I made some routines that when a person logged in, they defined some things that lasted for the lifetime of the session and that could be accessed by all forms and modules (and reports). I had no macros because they are a bit more tedious to manage if you are considering security. The user's login always came through a dispatcher form that stayed open during the session. It would define some permission-flag and department-related values that were in force for that user until he/she logged out. Each form had a Form_Open routine that check permissions and would pop up something if you were not supposed to use the feature. (This was on top of the dispatcher disabling buttons you weren't supposed to use.) The _Open routine would use the Cancel option to block access to the form as a whole. If you got in, the Form_Load routine would check for those permissions and might selectively disable certain functions. The Form_Current routine would, where appropriate, look at the just-loaded record to see if any department-specific factors applied. It wasn't easy and it took more than just a little while to get it all going... but I did get it pretty solid.

 

[smtazulislam]

Let me restate my point for clarity, as it seems there is been some misunderstanding. I have implemented everything as instructed, and the system itself is functioning perfectly. The issue is not with the functionality—it's with the process of assigning permissions, which becomes cumbersome and frustrating.

Whenever I attempt to configure permissions, I encounter difficulties that make the task embarrassing and inefficient. While everything else works as intended, this specific aspect of the process needs improvement.

Currently what I want to do for working on redesigning the User Manager Form to simplify the process of assigning permissions to users based on their roles. However, I have encountered challenges due to unexpected administrative requirements.

There are 29 users in the system, and initially, permissions were assigned based on predefined roles. Each role was configured with default settings, which could be applied using a single button.

However, the administration team has now expressed a preference for user-specific customizations within the same roles. This has created complications.

For instance, consider Role No. 1, which is assigned to three users, Like User A, User B, User C:
User A: Requires permission to access the "Salary Edit" feature.
User B: Uses the same Role No. 1 but must not have access to the "Salary Edit" feature.
The administrators want these users to remain under Role No. 1 but with varying permissions. Unfortunately, they did not communicate these requirements before the initial design phase, leaving me in a situation where the existing system cannot handle such granular changes efficiently.

To address this issue, I need to redesign the User Manager Form and modify the underlying code and database structure. I plan to introduce a subform for individual user overrides, allowing administrators to customize permissions for each user while still adhering to the broader role structure.

Currently, managing these exceptions requires manually checking and editing each line of code, which is both time-consuming and prone to error. The redesigned form will simplify this process and make it easier to manage user-specific permissions without affecting the integrity of the role-based system.

as someone adviced and I did like: "Selected Object Type by Combo box" with Event After Update and A textbox for Seach anything with Event Change.. (See the GREEN Color)

Its little make easy.
Do you have any others idea ? thank you.

 

[The_Doc_Man]

For instance, consider Role No. 1, which is assigned to three users, Like User A, User B, User C:
User A: Requires permission to access the "Salary Edit" feature.
User B: Uses the same Role No. 1 but must not have access to the "Salary Edit" feature.
The administrators want these users to remain under Role No. 1 but with varying permissions. Unfortunately, they did not communicate these requirements before the initial design phase, leaving me in a situation where the existing system cannot handle such granular changes efficiently.

In plain words, the administrators screwed up and gave you bad answers to your pre-implementation fact-finding survey (a must for any project having to do with a bunch of users) and now they are complaining. It means that Role #1 isn't always Role #1.

I would suggest a re-survey to see exactly how many variant roles you have. If you only have a couple of variants, I would suggest making up a couple of new names and create the new roles to have the appropriate extras. If you have a proliferation of variants, what I did was I created a list of "exception" flags - like Windows privileges in a way - that allowed for specific accesses. When your user logs in, not only would you look up the role, you would also look up privileges that a user could hold. Store these in something with public scope, such as either the declaration area of a general module or in some sort of TempVars structure that you could easily query. Then for those app features that are affected (e.g. the form that edits salaries), have them check not only the role but the presence of these "privilege" flags.

 

[Pat Hartman]

Give the users three spreadsheets. Sheet1 has Objects listed down the left side with roles across the top. Their instructions are to map objects to roles. Sheet2 has Users listed down the left side with roles across the top. Map users to roles. Sheet3 has Objects down the left side with users with additional non-role requirements across the top.

Now your application has to use a union query instead of a simple query so it can pick up objects mapped by role and objects mapped directly.

Change your interface to mimic the data from the spreadsheets.

Forcing the users to do the mapping makes them think about how roles are actually used. Perhaps there is only one role that was causing a problem and just splitting it into smaller pieces could let you stick with your original plan.