Is it possible to query, and or change permissions that are stored in a Microsoft Access *.mdw
security file?
I'm getting really tired of using the UI to list the permissions for each user and write them all down to see what they are...I looked at the titles of the MSys*
tables and I don't see anything in there that looks like a user or a permissions table (well at least in the database I'm connected to with the file...my guess would be that it's in the *.mdw file, somewhere but that I can't get to it through the database I'm connected to. I have admin rights, so that isn't it.
You can certainly write code to change user permissions.
It is 100% your choice to limit user permissions to membership in security groups. If you by sheer discipline follow this rule then the user’s permissions are NEVER stored in the database but only in the workgroup file. This thus makes management VERY easy. (hopefully this was done in your case).
You of course can choose to NOT follow the above rule and the result is now user permissions will exist in both the workgroup file and that of the database. This of course creates a real mess since then you cannot develop on a copy of the system off site for example. And management of security then becomes a real zoo.
I suggest a UI like this to select a user:
Then next screen is this to edit/assign that user to a security group.
The result is a VERY simple UI. So to give the user permissions such as being allowed to back date invoices etc. is now a simple mouse click to “select” the given group. That click thus gives the user in question “membership” in that security group.
The code to add a user to security group is this:
The code to remove a user from a security group is this:
The code to change a user password is this:
And for group membership I use this:
So I much suggest you organize these applications by security groups. The result is then it becomes one simple operation to give the sales group people use of some new feature in place of having to 25 sales people one by one to some form. By eliminating this “repetitive” process then you not need to wholesale update users security, but only assign users to security groups.
Using some logical security groups can often eliminate much of the need to update “many” users since you now just adding one thing to a given security group in which “many” users have membership. This “suggestion” applies to windows domain systems when managing desktops, or to Oracle or in this case a simple desktop system like Access.