Hi Justin,
This dual workgroup file is still a bit confusing to me...but just because
a user is part of Admins in the production.mdw, that doesn't mean he
actually have admin rights over the database, right?
For the most part that is correct.
But he just has admin rights to add/remove users? So that would also mean...
the only reason why anyone would be on Admins would be that the user
just needs to add/remove users...and nothing else..?
In the production MDW file, yes.
This is because I don't want to use the User and Group Accounts options by
MS Access. I created a form for it already and I have more control over it...
Bingo....
If I want to make a group thats actually like the Admins in develop.mdw, I
would have to create a new group, and grant most of the permissions to
them, right? So for a Department Director, he would be in the Admins group,
and a....SuperAdmins group?
You mentioned develop.mdw, but I wonder if you actually meant to say
production.mdw? You really only need your SuperAdmin in the develop.mdw
and no one else (except the default Admin user which you cannot remove).
And to correct any previous miscommunication on my part, you really only
need the Admins, Users, and whatever other custom groups you create in the
develop.mdw and production mdw files. You do not *have* to have a SuperAdmins
group.
I knew this was coming. I was just waiting for you to bring this up!! In my previous
post I composed some thoughts about this, but I decided to remove it at the last
moment. I wanted to first see if this was going to be an issue and sure enough you
brought it up. Of course I clearly remember that we helped you create custom forms
for replacing the functions and now you are wondering why you cannot use them!
OK, here are some things that you (and your boss) will need to think about. I will
try and be as clear as I can and explain what I did and why. Joan and Lynn, please
correct me if I am mistaken any where in here.
I created a development.mdw and production.mdw file. I have one SemiAdmin person
in the production.mdw file and that is the only person in the Admins group. I created
custom forms for adding/editing/deleting users (and assigning to groups) for four reasons:
- I work with very low tech users and there is no telling what they could screw up.
Exposing the Security dialog boxes to users is way too dangerous in my opinion.
Granted what they could screw up would be quite limited in the production.mdw,
but I wanted to minimize the potential problems as best I could. It is too long
of a story to put here, but I HAD to minimize the number of support calls.
- The SemiAdmin person could add and delete custom groups which is something
I most certainly did not want to have happen! Yes, they would not be able to assign
object permissions to new groups they created, but again I just didn't want them
adding unneccessary stuff and then call me with questions about it.
- The SemiAdmin person can turn off the Shift key bypass since they are a member
of the Admins group! I did not want to have this happen. Period.
- There was the possibility (and still is) that this application may at some time become
a Runtime application. Well, you cannot access the Security menus in a Runtime
application so I really was left with no choice but to create custom forms.
So what I did was make the SemiAdmin person "invisible." I shipped the application
with the production.mdw file. Included in the production.mdw were the following:
1. My SemiAdmin user in the Admins Group
2. One default person in a group like AppAdmins called Administrator
3. One default person in a group like AppUsers. (Just there for demonstration purposes)
When they first open the program I instruct them to log in as Administrator and give them
the password. I then show them how to create new users and assign them to either of
the two groups. We then delete the two 'default' users that came shipped with the
production.mdw file. They are then ready to go. I do not tell them about the SemiAdmin
user because there is no need. My custom security forms do all their functions in
a temporary workspace of the SemiAdmin's specs (which we have already discussed
at length).
The SemiAdmin user is NEVER presented on my custom security forms. Any combo
boxes that have a list of users do not have the SemiAdmin listed. Out of sight, out
of mind. No questions asked if they never know about it.
Will this setup work in ALL situations? Certainly not! It worked in my situation but
that does not mean it will work in your enviroment. My setup was single workstation
(no network issues) with only a tiny handful of users. You might be asking, "What
happens if a disgruntled person deletes everyone in the production.mdw before
leaving? How will they get back in?" That's easy. Pop in the CD, copy over a
backup copy of the production.mdw and start over. Recreate the users again.
This works for ME becuase we're talking about 5 or less users. This would of
course not be very feasible on a network with lots of users!
So you and your boss now are presented with a choice. Do you want the SemiAdmin
person to see the built-in security menu forms and have that person's log-on specs
be known to other people beside yourself and maybe the boss? If not, then you
will have to use the temporary workspace procedure that we already set up. You will
of course then have to hard code in the SemiAdmin's log-on specs into the code
and try to hide it as best as possible. Your boss has already said they do not like
this approach, but at this point you need to present your boss with all the information
and let them decide what they want to do. Both have advantages and disadvantages
so weigh them carefully. I am not tying to persuade you to one side or the other. I
am only trying to give you as much information as possible so you and the boss can
make an informed decision.
One last thought. There are utilities out there (some even free) that can read the
UserName/Password information from MDW files. So even with all of my trouble,
yes, my application could be hacked. But, that is the limitation of a Jet database
since it is a file-based system. NO amount of effort spent securing a Jet database
will keep out a determined hacker with access to the file itself. Period. You
just have to live with it or switch to another platform. I do not have any issues
with hackers so my setup works in my situation.
Man, this seems to get more confusing as I get closer to solving the
problem. Thanks in advance!
Access security *is* confusing the first few times around.
Don't feel bad, we've all been there before (except maybe Joan and Lynn)
PS: how do quote from a previous post? like...
I do not know how AccessMonster works, but it is probably a limitation
of that newsreader. I use Outlook Express and it is a piece of cake to
copy/paste text from previous messages.
