How to limit usability of Access objects per user?

[amorosik]

How to implement a generic functionality limitation system for some users of the Access procedure?
Let me explain, let's suppose that the access to the Access procedure is granted to users user1, user2, user3
Suppose you want to allow the user user1 to do everything, the user2 to do everything but only read in the frm123 form, and the user3 to enter all the forms and reports but only read, without being able to modify anything
How to create a system that allows you to define with good granularity the functions (read/write/execute) available on each object (form/report/module) available in the procedure?

 

[The_Doc_Man]

The correct topic to search in this forum is "role-based security." However, in order to implement this, you also need to research "securing a database" because if the DB isn't tied down tightly, role-based security won't work.

 

[mike60smart]

How to implement a generic functionality limitation system for some users of the Access procedure?
Let me explain, let's suppose that the access to the Access procedure is granted to users user1, user2, user3
Suppose you want to allow the user user1 to do everything, the user2 to do everything but only read in the frm123 form, and the user3 to enter all the forms and reports but only read, without being able to modify anything
How to create a system that allows you to define with good granularity the functions (read/write/execute) available on each object (form/report/module) available in the procedure?

Hi

This Link has a complete example of how to do this

 

[Pat Hartman]

Here's a simple example. It assigns add/delete/read/update for each object and for each user. There is code in the relevant procedures - Open, Beforeinsert, BeforeUpdate, Delete that matches the level for that action for the active form against the user's level for that action. Using the switchboard table to implement this allows you to hide/show items based on the users permissions.

Switchboard with simple security

This is a custom switchboard. It expands on the Switchboard Items table to add four additional columns to define view/edit/add/delete security levels for switchboard items and forms/reports referenced by them. It includes tables to manage users and also to assign them security levels. The user...

www.access-programmers.co.uk

There are more granular solutions but this is an easy to implement middle ground.

 

[amorosik]

Hi

This Link has a complete example of how to do this

I would like to publicly thank Vlad Cucinschi who kindly offered to send me a working copy of his demo program for user management
The one available on the website didn't seem to be working properly
I wrote to him and he sent me a working copy of the demo

 

[GaP42]

I downloaded this too and as found it required 64bit conversion.

I would like to publicly thank Vlad Cucinschi who kindly offered to send me a working copy of his demo program for user management
The one available on the website didn't seem to be working properly
I wrote to him and he sent me a working copy of the demo

Changed some declarations to 64bit to get it working - was that the problem?

 

[bastanu]

Yes, the version I have on my site is an older 32 bit one, there are a couple modules that need to be updated to be compatible with 64 bit or have conditional compiling to make them work with both.
Cheers,
Vlad

 

[GaP42]

I hope then you will make your 64bit update available @bastanu Thanks.

 

[gemma-the-husky]

@amorosik

I think the real problem relatives to the atomic-ness of allowing users to manipulate forms.

If you want to allow/disallow users opening forms, then you can have a user system with permission levels, and a forms table declaring the required permission level. Then in every form's open event test whether that user can open the form.

Sort of

If not(CanIOpenThisForm(me.name) then
Msgbox "Sorry, you cannot use this form")
Cancel=true
Exit sub
End if

So all you need is to change each form's open event to include a standard function to test the users access level.

However if you want to limit a user's interaction within a form, then every little interaction needs to be programmed carefully which makes it much harder to achieve.

 

[Pat Hartman]

If you want to allow/disallow users opening forms, then you can have a user system with permission levels, and a forms table declaring the required permission level. Then in every form's open event test whether that user can open the form.

And that is exactly what my sample does

 

[bastanu]

Here is an updated version that should work with both 32 and 64 bit versions of MS Office (it allows to control access to individual control level).

Cheers,

 

[amorosik]

@amorosik

I think the real problem relatives to the atomic-ness of allowing users to manipulate forms.

If you want to allow/disallow users opening forms, then you can have a user system with permission levels, and a forms table declaring the required permission level. Then in every form's open event test whether that user can open the form.

Yes, this is what I'm trying to accomplish
Of course, modifying the content of some events on many forms/reports is a very expensive operation
If there was the possibility of acting "from the outside" it would be a great thing
But I imagine it's not feasible

 

[gemma-the-husky]

I slightly simplified my explanation before. As well as setting access levels required to open particular forms, you can also include user groups. So you add your user to user groups, and the access to forms is then controlled by the user group membership together with the individual users access level.

I imagine the example provided by @Pat Hartman includes user groups.

You can also actually write code to iterate your code modules to check whether the code blocks you want are present in each forms open event, and insert the code if it isn't there. It needs a bit of thinking about to get it to insert correctly, and an appropriate understanding of the process, but it's a real time saver for a big database.

 

[bastanu]

My sample uses table-based "access rules" at the form and control level so no need to hard-code individual control or form events. Everything happens in the Open form event and it is just one line:

Call vcSetAccessLevels("Form", Me.Name)

Cheers,

 

[Pat Hartman]

I imagine the example provided by @Pat Hartman includes user groups.

It does. Adding security after the fact requires code changes. You can't get around it which is why it is always better to know at the beginning whether or not you need security. Anyway. You have four if statements that need to be added to four events in every form. Put the code in a text file and leave it open. Using copy paste - the code you are adding always goes in as the first instruction in the procedure -you can do each form in a minute or two. Tedious but doable. I think the update procedure would be approximately the same regardless of which method you adopt.