tab control & user level security

  • Thread starter Thread starter chris
  • Start date Start date
C

chris

I have an application (Access XP, A2K format, split db) that has a lot
of forms. It also has user level security and about 10 security
groups. Now the customer would like to reduce the number of forms and
suggests the use of tab controls with several pages.
I know it's possible to look for group membership in the open event of
a form and consequently hide/display certain pages but is there no way
to keep the permissions that have been set up for the subforms? It
seems a lot easier to manage than have to recode when new groups or
pages are created.
At first sight, a user must have access to all subforms on the pages
of a tab control, otherwise he gets a security error. Am I right?
Someone have a clue? Many thanks in advance
Chris
 
You forsee a solution where a tab page has several subforms, and the current
user has access to >some< of those subforms but not all of them (because of
user-level security restrictions)?

I have never tried that & do not know the answer. But it should only take
you a few minutes to set up a small test & try it for real.

However, even if you >can< do that, I would recommend against it, from a
user interface viewpoint. IMO, if a user can access a certain page in a tab
control, he should be able to access the full content of that page -
including any/all subforms on that page. Could you not design your pages to
meet that requirement? Would that simplify the redesign?

As for how to "keep the permissions that have been set up for the subforms",
I'm not sure what you're getting at there. Please give a bit more detail.

HTH,
TC
 
Sorry if I wasn't clear. I'd like to restrict the access at tab page
level. (once a user has access to a tab page, he may see/access
everything on that page).

About the permissions: the thing is we spent a lot of time and efforts
setting up security groups and the proper permissions for each object
in the db. It seems a bit funny to me that this system does no longer
function when those objects (e.g. forms) are used on a tab page. I
would have liked Access to display a security message when a users
tries to activate a tab with an object he has no permissions for. But
apparently as soon as there is 1 tab page with such an object, Access
refuses to open the main form (the one with the tab control). So I am
forced to foresee in the code of the open event which tab pages to
hide/display based upon the users membership of security groups. But
than it's me doing the security management I thought Access would
do...

chris
 
Chris,
I'm puzzled as to why you don't simply hide a tab page from users that do
not have permissions to the content of a given page?
 
So, let me see if I have this right.

- The previous system had user A with permission to use form F, and user B
without< permission to use form F.
Click to expand...

- The new system has a main form M with a tab control with form F as a
subform on one of the pages (say page #3).

- You expect that when user A runs form M, he will be able to go to page #3
and use (sub)form F. This does occur.

- You further expect that when user B runs form M, Access will stop him
going to tab page #3, because that page contains an object (F) to which he
does not have permission. But that does >not< occur. Instead, Access will
not let user B run form M at all, due to the presence of that non-permitted
object F.

- You would like somehow for Access to work the way you thought that it
should, in regard to user B, as described in the previous point.

Correct?

If so, you could maybe do something like this. It is possible to determine,
through code, whether the current user does or does not have run permission
on form F (when F is used as a main form). Form M could use that code to
enable, or disable, tab control page #3, accordingly; or to enable or
disable the subform control on that page. Then you could retain the benefit
of your previous security assignments.

With some careful coding, you could even make this general purpose; that is,
a standard procedure that every form could call, from its Open or Load
event. That procedure would search the form (at runtime) for subform
controls; see whether the current user did or did not have permission to use
the form in each subform control; and enable or disable the subform
controls, accordingly.

Does that help?

TC

PS. I only get one session on the net, per day. So I will not see your reply
until tomorrow afternoon.
 
I think he's asking how to do that in a general purpose way that takes
advantage of his existing security settings. See my other reply.

Cheers,
TC
 
Thanks for replying. TC, you perfectly resume what I would like to
achieve! (wish I would have been that clear from the start...)
I certainly retain your suggestion about testing whether the user has
run permissions:
1. could you give me a clue on the properties to check?
2. do you think this would mean a major performance penalty? (say a
form with some 10 subforms for which permissions need to be checked)
Tia,
Chris
 
Chris, on reflection, I think that my suggested approach (of disabling the
subform control, or the tab page) will not work in the way I suggested. If
Access refuses to let user B run form M, because of the presence of subform
F, then, the code in M will never get a chance to disable the relevant tab
page or subform control! Catch 22. So let's take a different approach, but
still with the aim of retaining your existing security settings.

If Access will not let B run M because of F, then, we can not have F in the
subform control initially. Perhaps, instead of trying to hide or disable the
subform control (when appropriate), we should have >no< form in there
initially, then >add< the form when appropriate. With that approach, >any<
user can run M, then M decides which subform controls to actually put the
subforms into.

Normally, the name of the (sub)form is placed in the SourceObject property
of the subform control. Let's say instead, that we leave sourceobject blank,
and put the (sub)form name in the Tag property, instead. Say we follow that
rule for every subform control on form M.

Then, the following code, when run from form M, would find each subform
control - get the proposed (sub)form name from its Tag property - enable
error trapping - try to set that form into the subform control - and if an
error occurs, disables the subform control.

(untested)

dim ctl as control
for each ctl in me.controls
if ctl.type = acsubform then ' ctl.type or typeof ctl? - can't
remember.
on error resume next
ctl.sourceobject = ctl.tag
if err.number <> 0 then
' no can do!
ctl.enabled = false
endif
on error goto 0
endif
next

Rather than trying to see if the user has run permission on the (sub)form,
I'm assuming that a trappable error will occur if he doesn't, and you try to
set that form into the subform control.

The above solution does not manage the LinkMasterFields & LinkChildFields
properties. The existing values are probably erased when you change the
subform control's sourceobject property. So you'd need code to set those
properties back to their original values. Maybe you could save them in
string variables immediately before the ctl.sourceobject= line, & restore
them afterwards.

I don't have Access on this PC, so this is all off the top of my head. I
hope you can make something of it. However, I'm confident that what you want
to achieve, is realistic & achievable.

HTH,
TC
 
And P.S.:

None of this would have any performance impact. You need not worry about
that, at all.

HTH,
TC
 
Hi TC, thanks again for your time. I understand the problem with the
first suggested approach. I will try to implement the second one
somewhere next week. Will surely give you feedback. Thanks a lot,
Chris.
 
Back
Top