Re: tab control & user level security
From: TC (no_at_email.here)
Date: 04/01/04
- Next message: TC: "Re: Deleting records"
- Previous message: TC: "Re: tab control & user level security"
- In reply to: TC: "Re: tab control & user level security"
- Next in thread: chris: "Re: tab control & user level security"
- Reply: chris: "Re: tab control & user level security"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 1 Apr 2004 12:33:12 +0930
And P.S.:
None of this would have any performance impact. You need not worry about
that, at all.
HTH,
TC
"TC" <no@email.here> wrote in message
news:406b8134$1_3@news.chariot.net.au...
> 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
>
>
- Next message: TC: "Re: Deleting records"
- Previous message: TC: "Re: tab control & user level security"
- In reply to: TC: "Re: tab control & user level security"
- Next in thread: chris: "Re: tab control & user level security"
- Reply: chris: "Re: tab control & user level security"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
