Re: tab control & user level security

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: TC (no_at_email.here)
Date: 04/01/04 

Date: Thu, 1 Apr 2004 12:13:01 +0930

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

"chris" <chrisderoover@hotmail.com> wrote in message
news:90bdd240.0403311417.11761cf2@posting.google.com...
> 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
>
>
> "TC" <no@email.here> wrote in message
news:<4068d416$1_2@news.chariot.net.au>...
> > 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.
> >
> > - 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.
> >
> >
> > "chris" <chrisderoover@hotmail.com> wrote in message
> > news:90bdd240.0403290109.6801bf35@posting.google.com...
> > > 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
> > >
> > > "TC" <no@email.here> wrote in message
> > news:<40677dc5_3@news.chariot.net.au>...
> > > > 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
> > > >
> > > >
> > > > "chris" <chrisderoover@hotmail.com> wrote in message
> > > > news:90bdd240.0403280840.24000386@posting.google.com...
> > > > > 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

Relevant Pages

  • Re: tab control & user level security
    ... 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. ... F, then, the code in M will never get a chance to disable the relevant tab ... > I certainly retain your suggestion about testing whether the user has ...
    (microsoft.public.access.forms)
  • Re: tab control & user level security
    ... > 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. ... > HTH, ...
    (microsoft.public.access.forms)
  • Re: tab control & user level security
    ... > 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. ... > HTH, ...
    (microsoft.public.access.security)
  • Re: Sub-SubForm Reference Problem
    ... Per David W. Fenton: ... You mean disabling the subform control that has the offending form as it's ... even to the point of implementing across all of my forms/subforms ...
    (comp.databases.ms-access)
  • Re: Activating and deactivating a FORM
    ... Allen Browne - Microsoft MVP. ... > How can I close the sourceObject that I placed in the subform control? ... >> the tab control), you can make the tab control quite squat (just tall ...
    (microsoft.public.access.forms)