Thanks! That’s what I was looking for… I still need some clarification though, so I understand well. Let see if I get this right :
In my case, I have to make the distinction between “Operators” and “Suppliers” as the app layout has to be different depending of the type of user. For each of them, I have a distinct set of roles and permissions that looks like this :
ROLES table
- SUPPLIER_ADMIN, SUPPLIER_USER, SUPPLIER_GUEST
- OPERATOR_ADMIN, OPERATOR_USER, OPERATOR_GUEST
PRIVILEGES table : ADMIN privileges > USER > GUEST.
- ADMIN : VIEW_ADVANCED, VIEW_BASIC, EDIT_BASIC, EDIT_ADVANCED
- USER : VIEW_BASIC, EDIT_BASIC
- GUEST : EDIT_BASIC
For example, in my application I have a container called “UserProfileDetailsWC1” (which is an instance of a custom Class called “UserProfileDetailsWC) that shows user profile informations”. I use a function named “Update_User_Profile(refValue As Integer)” too save the modifications to the profile.
The way a user accesses it is different depending on his ROLE :
- ADMIN sees a user list in which he can select a user and see his profile
- USER AND GUEST are directly sent to the see their own profile.
The update functionality behaves differently for each ROLE as well :
- ADMIN can edit and update any field
- USER can edit and update some fields
- GUEST can’t edit neither update his profile
When you say : [quote=339486:@Louis Desjardins] In another table, the key is page (container) and function code. This is used at the highest level to determine whether a user can see a page at all. Then, in a few other tables, I have the page-function code plus various other specific key fields. The permission is assigned as a parameter. It can be nil or 0 - access denied to 99 - full admin. Access is defined at various levels (page-function code or more specific) specifically for each page or container, function code (create, edit, display, list etc.), transaction-specific parameters and of course, user parameters.[/quote]
What would i find is in this other_table and the other_tables, what is the key? Would it be the container name and the function name?
How I see it for the other_table
- In the other_table , I would have a key made of two columns ( col1 = “UserProfileDetailsWC1”, col2 = “Update_User_Profile”)
- plus an additional column for each combination “role-privilege” (SUPPLIER_ADMIN_VIEW_ADVANCED, SUPPLIER_ADMIN_VIEW_BASIC, SUPPLIER_ADMIN_EDIT_ADVANCED, SUPPLIER_ADMIN_EDIT_BASIC, OPERATOR_ADMIN_VIEW_ADVANCED… )
- a value for each field that indicates if the user can or can’t see the container for every col1-col2 key and role-privilege combination
- a Function (that could use Introspection) that retrieves the Container.Name and the Function.Name and checks in the other_table what right is attributed to the user’s role-privilege combination.
- based on the value returned by the Function, the code will show a MsgBox, or open the container.
How I see it for the other_tables CASE OTHER TABLE 1 = go to list Or go directly to profile
- In the other_table , I would have a key made of two columns ( col1 = “UserProfileDetailsWC1”, col2 = “Update_User_Profile”)
- plus an additional column for each combination “role-privilege” (SUPPLIER_ADMIN_VIEW_ADVANCED, SUPPLIER_ADMIN_VIEW_BASIC, SUPPLIER_ADMIN_EDIT_ADVANCED, SUPPLIER_ADMIN_EDIT_BASIC, OPERATOR_ADMIN_VIEW_ADVANCED… )
- a value for each field that indicates if the user opens the list prior to access the profile view or if he is directly sent to the profile view container and that for every col1-col2 key and role-privilege combination
- a Function (that could use Introspection) that retrieves the Container.Name and the Function.Name and checks in the other_tables 1 what right is attributed to the user’s role-privilege combination.
- based on the value returned by the Function, the code will redirect the user to the list or the profile view.
How I see it for the other_tables CASE OTHER TABLE 2 = “updatable fields”, update Or NOT update profile
- In the other_table , I would have a key made of two columns ( col1 = “UserProfileDetailsWC1”, col2 = “Update_User_Profile”)
- plus an additional column for each combination “role-privilege” (SUPPLIER_ADMIN_VIEW_ADVANCED, SUPPLIER_ADMIN_VIEW_BASIC, SUPPLIER_ADMIN_EDIT_ADVANCED, SUPPLIER_ADMIN_EDIT_BASIC, OPERATOR_ADMIN_VIEW_ADVANCED… )
- a value for each field that indicates fields set, can update or not and that for every col1-col2 key and role-privilege combination
- a Function (that could use Introspection) that retrieves the Container.Name and the Function.Name and checks in the other_tables 2 what right is attributed to the user’s role-privilege combination.
- based on the value returned by the Function, the code will enable all some or no fields and the save button.
Is that the kind of pattern you were describing?
At first glance, It appears to be a lot of work… If I’m right, is there a way to simplify that?
Thanks again!