Patrick said:
Dear Douglas,
Many thanks for your reply.
If Group and User permissions are set up in the MDB file and the MDW file
is stuffed up
Sure what you mean by the terms stuffed up, But I will point out a very
important concept here that's not been clarified.
note that you can store group and user permissions in an MDB, but you SHOULD
NEVER EVER store actual users permissions in the actual mdb file. in other
words you have a choice here that you can make, and you should always assign
users names to a particular group, and that group membership is defined in
the mdw file.
The reason why the above is important is assume that you have a whole bunch
of clients all over the world and you've developed an application that
you're selling commercially (or perhaps you developed something within a
small tiny departing within a large corporation, it really doesn't matter).
if you are ways to sign users to a particular group that's defined in the
MDW file, then you're free to issue new updates of your software to all the
users with great ease, and none of their permissions that they set
themselves will ever be overwritten.
The instant you start assigning permissions to a particular user in an MDB
is the very same instant when you will be unable to start developing or
modifying that software offsite or using a copy of that software (the mdb
file) to make modifications while you're away, or just perhaps working on
the next great and release of the software while the users are using the
current version of your software.
what this means is that when you design your software, you should make a set
of particular groups that you want users to be a member of, usually it's
quite easy to define this. I have for example the following groups in my
application:
SecGroup SecDescription
AddTours Add Tours, Rooms, Wholesale Tour Pricing
Admins Administrator (Add users, change passwords)
Basic Basic Rides
DailyReports Daily Reports
InvBackWard Can back date invoices payments
InvDelete Can delete invoice payments
InvForward Can forward date invoice payments
RidesGroups Allow creation of Corporate Tours
SeasonReports Seasonal sales Reports
So the above is the list of the security groups I've defined in the
application. From that point over the life of development, if there's a
particular season or sales report created that you don't want your general
staff to be able to view, then don't include that report in the "Basic"
group. ONLY those who are a member of the "SeasonReports" group can view
that report.
So it's quite easy and practical to the build a list of particular security
levels or groups that you want in an application. You then the assigned
things like forms, reports, and tables to that particular set of groups.
notice how we're never assigning any of the report's or forms objects in the
database directly to an actual user, but we ONLY use groups.
What this means is that I'd never add or remove or change these groups.
Remember, while you can create permissions for both users and groups in a
mdb file, if you ALWAYS assigned users to group membership, that group
membership is contained in the workgroup file and NOT the mdb file. The
only
permissions we are signing in the actual database or application (mdb file)
is what groups can do what particular task. If you create a new report, and
only want the sales group to be able to the see these reports, then you
assign the report to the sales "group". Note how we're never actually
assigning users to that particular report, and therefore were never actually
setting any user permissions inside of the mdb file.
To make the above long story short, while it's possible to store users
permissions in the actual database file in real practice you want to
to positively avoid this.
, how can we change the Group and User permissions
For users permissions and what group they belong to, you do NOT even have
to open the mdb file/application Simply Launch access, and go
tools->Securty->users and group accounts
Note how we NOT even Open to any application yet, remember when access
starts up the first thing a user does is login. This workgroup file is
attached to the user at logon (you cannot opener launch MS access without
being attached
to a particular workgroup. This occurs before ANY application that may have
some permissions set. So, when you launch ms-access you ALWAYS WERE using a
workgroup file, even in those data bases that are not secured.
If there is a password on the admin account, then users will always get a
logon prompt. So, it is good idea to set a particular workgroup file for a
particular
application. the only real practical way to do this is to set up a
desktop shortcut that specifies the workgroup file to use (this is a very
good idea if you only have one secured database, and you don't want all
users to get naged all day with a logon prompt all day long when they launch
other access applications).
so you can create users and assign them to Group permissions by using the
above option.
If you want to "reports", or "tables" or whatever to particular "groups"
(Remember you can assign them to users, but that's a very bad idea as then
you're setting users permissions inside of the actual application, and we
don't wanna do that for the above reasons). To assing
reports/tables/quires/forms etc to a particlar group, go
tolls->securty->User and group permissions
Note while the above is user and group permissins, we "only" are going to
use the group p3rmisosns here. When using this option, you are setting
permissons in the applciaon, not the workgroup file.
So, you "do have" a choice as to where the permsisons For each user are
going to be stored, and if you're smart about this, you only Everett act
users to a particular group, and never assigned individual particular
permissions to a report or form to that one user. as mentioned, this ensures
that you never assigning actual database permissions to a particular user
inside the actual data base itself, everything is contained within the
workgroup file. this is important as then you're free the able to issue a
new software updates and new versions of your software even when you're off
site, and not even part of that particular workgroup file. you almost
certainly have a copy of that work group filed during the development
process, but is the customer or client that is able to sign users to those
particular groups within the workgroup security file.
view what users have been set up ?
tools->securty->users and group accounts.
There is a opton to printout each user and their memberships in each
group....
