Thanks, Rick. Whenever I copied a frontend to bring it home to work, made
some changes to the permissions, and then copied it back to the office,
the
permissions go haywire so I'm wondering if I should also copy the mdw as
well
whenever I need to make changes to permissions.
Well, you would have at least needed a copy of the workgroup file. If you
can move the mdb file to different machine, and open it with a different mdw
file, then your security has been setup wrong (what kind of security would
that be?). So, you can ONLY open the mdb file with the original workgroup
file used to secure it. (or a new workgroup file created with the same
passwords used).
Assuming, thus that you likely do have a copy of the workgroup file at home,
then, yes..you can make security changes, and take them back to work.
However, keep in mind two things:
You should NEVER NEVER set security for a form, report, query etc to a
actual INDIVIDUAL!!! The INSTANT you do this, you have now in fact put
security for users in the mdb file. You have a choice here:
when you set security/permissions for a form, report etc, ALWAYS set
those
permissions to a SECURITY GROUP not a USER!!!! By doing this, means you
can work on a copy of the front end, and also take home a copy of the
security workgroup file. During the week, I sure that new users are being
added to the system. Further, I sure over time, some users will be given
permissions to use a particular form etc. However, since we ALWAYS assign
users to security groups, then in fact we NEVER assign a user to a form,
but only security groups.
This means that as you add new forms, or reports in your application, you
simply assign that report, or form to a EXISTING security group (say, the
sales group, or perhaps the manager group, or the 'read only' group). This
way, you can re-deploy a new front end to the company on site, but develop
off site. All of the many complex changes and assigning of users to security
groups will thus continue to work, and yet you don't care, or even need
their security workgroup file.
The instant you break the above rule, and start assigning forms to actual
users, then in fact that security is CONTAINED IN THE MDB file!!! So, don't
do
that!!
At the end of the day, most applications I have written can be broken down
in to maybe 3, or 5 major security groups. There is some great screen shots,
and an example of the security groups I used here:
http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm
So, the major trick to making this work is to sit down, and build 3 or 5
security groups. Then as you develop the application, you ALWAYS assign
forms
and reports to those security groups. It is only your clients that will
assign users to those actual security groups, but those settings are
contained in the workgroup file. So, you have 100% complete freedom to
email, or simply update your users front end.
The instant you allow your client to add new security groups, or allow them
to assign users to a particular form, then any update you send to them will
LOOSE those settings.
So, as a developer, make the security groups for the client, and as you
develop, assign forms, reports etc. to those security groups.
And, like I did, you might want to spend part of a afternoon, and make a few
nice security manager screens that makes this stuff VERY easy for your
clients...
