CurrentUser vs Group Member
Bonnie
If CurrentUser() <> "BWA" And CurrentUser() <> "KXK" Then
MsgBox "You are not authorized to use this form." Else
Is is possible to name a Group instead so I can edit
members of a permissions group and not have to change each
occurrance of the above in each DB?
Crossing my fingers, cause that would make my life MUCH
easier with folks shifting through various security
levels. Thanks in advance for any help or advice on this.
Brendan Reynolds
String) As Boolean
Dim wsp As DAO.Workspace
Dim grp As DAO.Group
Dim usr As DAO.User
Set wsp = DBEngine.Workspaces(0)
Set usr = wsp.Users(UserName)
For Each grp In usr.Groups
If grp.Name = GroupName Then
IsUserInGroup = True
Exit For
End If
Next grp
End Function
--
Brendan Reynolds (MVP)
"Bonnie" <anon...@discussions.microsoft.com> wrote in message
news:13d6601c3f7b4$898514c0$a601...@phx.gbl...
Bonnie
would it be possible for just a little blow by blow as to
where I should write this and where do I refer to the
specific group name (Admins) that I'm checking for and can
I use it for OnClick or OnOpen events? I pasted it in a
new module I named UserGroup.
Each of my DB's has group levels for viewing, various
editing and administrative processes. Some forms should
only open for those in the group Admins. How do I
accomplish this? Again, thank you VERY much for your help.
>.
>
Brendan Reynolds
report or control event procedure, or even use it in an expression in a
control source or in a query.
A user can be in more than one group, so the idea is that we use the
function to determine if the user is in a group that should have access to
the feature in question. So where we'll use it depends on how the specific
feature is accessed. The function takes two arguments, the name of the user,
and the name of the group in question. It will return true if the specified
user is a member of the specified group, otherwise, it will return false.
So, if for example we have a command button that opens a form, and only
members of the Admins group have permission to view that form, we could use
the function like so in the Click event of that command button ...
If IsUserInGroup(CurrentUser(), "Admins") Then
'open the form
Else
'tell the user he/she can't view this form
End If
Suppose members of 'Group1' have permission to open the form in read-only
mode, members of 'Group2' have permission to open the form in edit mode, and
those who are not members of either group don't have permission to open the
form at all ...
If IsUserInGroup(CurrentUser(), "Group2") Then
DoCmd.OpenForm "SomeForm", , , , acFormEdit
ElseIf IsUserInGroup(CurrentUser(), "Group1") Then
DoCmd.OpenForm "SomeForm", , , , acReadOnly
Else
'tell the user he/she can't view this form
End If
One more example ... suppose members of either 'Group1', 'Group2', or
'Group3' can open the form, but users who are not members of any of these
three groups can not open the form ...
Select Case True
Case IsUserInGroup(CurrentUser(), "Group1"), IsUserInGroup(CurrentUser(),
"Group2"), IsUserInGroup(CurrentUser(), "Group3")
'open the form
Case Else
'don't open the form
End Select
--
Brendan Reynolds (MVP)
"Bonnie" <anon...@discussions.microsoft.com> wrote in message
news:1326b01c3f7bb$89a2d1c0$a301...@phx.gbl...
Bonnie
explanation and examples make TONS of sense. I will work
on those VERY soon. I love these newsgroups!!!
>.
>
Albert D. Kallal
What you should do is simply make and create those user groups.
For example, in my last application I make the following groups:
Basic - Basic Rides user
DailyReports - Daily Reports
SeasonReports - Seasonal Reports
RidesGroups - Allow creation of Corporate Groups
InvForward - Can forward date invoice payments
InvBackWard - Can back date invoices payments
InvDelete - Can delete invoice payments
AddTours - Add Tours, Rooms, Wholesale Tour Pricing
Admins - Administrator (Add users, change passwords)
Then, when I add a new user to the system, I simply select from the above
list of groups that I want the user to be able to do. For example, in the
above I have:
Allow creation of Corporate Groups
That simply means that the user can open and use the Corporate Groups form.
If I go into the security setup, I simply set the permissions of the
"Corporate Group" FORM to the above user group. YOU SHOULD NEVER set
permissions of forms, reports etc to individual users. (and, it seems you
have got your system setup using this correct approach...good for you!).
The reason why you don't want to set individual users to any particular form
is that it becomes a nightmare to add a new user to the system. A
application can typically have a 100 or more forms...and trying to figure
out what form(s) a single user can use will be a maintains night mare.
So, the simple solution is to create some nice user "groups" and then assign
the user to those groups. It is all those groups where you do the hard work
of assigning of what group belongs to what form. Further, once you do this
assignment, then if a user does NOT have permissions to use a form, the you
don't even have to write ONE line of code (this is the whole idea of
implementing security in the first place). If you set the security of the
form to that group, then any user that tries to open or use that form MUST
be a member of that security group. So, really, you don't want to write code
to check, or test every form that you load. This is even more handy for
reports. Of course, about the only downfall of writing no code is that you
get a rather lousily error message. However, if you are building custom tool
bars/menu bars..then the code free solution is nice.
Also, to be fair...it looks like you done your security the right way, and
are simply asking how to check if a user belongs to a particular user group.
I often do this, but NOT usually for forms..since they each can be assigned
to a user group anyway.
However, I never did think that the built in security system is user
friendly from a user point of view. So I wrote my on security manager. You
can see some screen shots of it in action at:
However, note while I wrote my own security manager, I certainly do use and
rely on the built-in security to decide who can load and use what forms. I
do this since it saves tons of code, and in fact using security means you
can control with whole process with NO code at all!
Anyway, the code example posted could be used like:
if IsInGroup(CurrentUser(),"MasterUser") = true then
bla bla bla
end if
Or, in my above example, I have that the user can forward date invoices. So,
in this case I DO NEED to use the IsInGroup, since security is only assigned
to whole form. So, at this point once again I would use code. It looks like:
If (IsInGroup(CurrentUser(), "InvForward") = False) And _
(IsInGroup(CurrentUser(), "Admins") = False) Then
Beep
MsgBox "Forward dating of a invoice is not allowed", vbExclamation
Cancel = True
End If
You can see in the above example, the user must be a member of InvForward
group OR can be a member of admins.
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
pleasenono...@msn.com
http://www.attcanada.net/~kallal.msn
Brendan Reynolds
"Albert D. Kallal" <pleasenonos...@msn.com> wrote in message
news:MRqZb.561892$JQ1.262528@pd7tw1no...
> Really, why use any code at all?
> Of course, about the only downfall of writing no code is that you
> get a rather lousily error message.
I think you answered your own question there, Albert! :-)
Using code (in addition to security, not instead of it) can give you a bit
more flexibility in how you present and describe a problem to a user. Of
course I don't always do it that way - it depends on the type of person who
will be using the app and the development timescale and resources available.
It's one of those things that's nice to do if you can, but not essential.
It's the same reason why I check for potential duplicate records in the
Before Update event of a form. A unique index is going to prevent the saving
of a duplicate record anyway, but a more user-friendly message may mean that
the user doesn't need to call me on the phone for an explanation.
I'm glad you asked the question - looking back on the thread, I can see that
it wasn't necessarily clear that the code was intended to be used in
addition to security rather than instead of it.
--
Brendan Reynolds (MVP)
Bonnie
and I am excited about stepping up to this level. (I have
a few Supervisor forms in each DB and would REALLY love to
be able to use the IsInGroup. From there, it can open up
more possibilities. I do have userlevel security and it
works pretty well for what we have. Now, I'd love to use
the groups to determine who can do what. I really want to
be able to assign groups to my forms.
On my SetUp form's OnOpen Event, I put:
If (IsInGroup(CurrentUser(), "GIC") = False) And _
(IsInGroup(CurrentUser(), "Admins") = False) Then
Beep
MsgBox "You cannot use this form.", vbExclamation
Cancel = True
End If
I'm getting a 'Compile Error: Sub or Function not defined'
when I try to compile code. Focus is on IsInGroup in my
first line. Am I supposed to define it somewhere?
>.
>
Albert D. Kallal
> On my SetUp form's OnOpen Event, I put:
>
> If (IsInGroup(CurrentUser(), "GIC") = False) And _
> (IsInGroup(CurrentUser(), "Admins") = False) Then
> Beep
> MsgBox "You cannot use this form.", vbExclamation
> Cancel = True
> End If
>
> I'm getting a 'Compile Error: Sub or Function not defined'
> when I try to compile code. Focus is on IsInGroup in my
> first line. Am I supposed to define it somewhere?
Yes, you are supposed to put that IsInGroup function that Brendan gave you
into a standard code module (not your forms module).
As mentioned, you don't need any code to prevent that form load if you use
security, but using code is more work (and hence this question!)...but you
are able to customize the error message by wring code. Note that since the
above does a form cancel, then your code that opens the above form will get
an error..and you need to trap that, or ignore it.
on error resume next
docmd.Openform "the above form"
on error goto 0
As you can see, you have to error trap the form cancel anyway...so you
could in theory delete all of your code in the on-open, and trap for a error
code of permissions (ie: start setting permissions of the form..and NOT use
code as I mentioned).
Anyway, to get your sample code to work...did you put the isingroup code
into a
module? (and don't name the module the same as the isgingroup function..that
confuses ms-access.
Also, just re-reading my original post..I mentioned some screen shots of
using security...here is that link:
http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm
Joan Wild
if they aren't in the right group, don't even display the button that opens
the form.
I think users would get frustrated to be given an option, and then a message
saying 'you can't do that'. Don't even show it to them.
--
Joan Wild
Microsoft Access MVP
"Albert D. Kallal" <pleasenonos...@msn.com> wrote in message
news:t0wZb.577024$X%5.415455@pd7tw2no...
Bonnie
created a function in a module and (I took Joan's advice
on having the button appear or not - EXCELLENT IDEA!)
created a form with buttons that are visible or not
visible as well as (THANKS BUNCHES BRENDAN FOR THE BLOW BY
BLOW!) opening a form in various views depending upon
which group the user is a member of! (And KUDOS to Albert
Kallal for his great explanation!!!) And all using the
wonderful code to recognize if the user is a member of a
named group. I do indeed already have user level security
so you have to be a member of certain groups to even have
permission to open most of my DB's. Now I can put various
levels without multiple forms and open some to edit and
some to read only. I'm in a learning frenzy, folks! A
light bulb has come on!!! THANKS AGAIN!
>
Bonnie
created a function in a module and (I took Joan's advice
on having the button appear or not - EXCELLENT IDEA!)
created a form with buttons that are visible or not
visible as well as (THANKS BUNCHES BRENDAN FOR THE BLOW BY
BLOW!) opening a form in various views depending upon
which group the user is a member of! (And KUDOS to Albert
Kallal for his great explanation!!!) And all using the
wonderful code to recognize if the user is a member of a
named group. I do indeed already have user level security
so you have to be a member of certain groups to even have
permission to open most of my DB's. Now I can put various
levels without multiple forms and open some to edit and
some to read only. I'm in a learning frenzy, folks! A
light bulb has come on!!! THANKS AGAIN!
>.
>
Bonnie
created a function in a module and (I took Joan's advice
on having the button appear or not - EXCELLENT IDEA!)
created a form with buttons that are visible or not
visible as well as (THANKS BUNCHES BRENDAN FOR THE BLOW BY
BLOW!) opening a form in various views depending upon
which group the user is a member of! (And KUDOS to Albert
Kallal for his great explanation!!!) And all using the
wonderful code to recognize if the user is a member of a
named group. I do indeed already have user level security
so you have to be a member of certain groups to even have
permission to open most of my DB's. Now I can put various
levels without multiple forms and open some to edit and
some to read only. I'm in a learning frenzy, folks! A
light bulb has come on!!! THANKS AGAIN!
>.
>