We do security by user groups rather than individual users, so we say "what
group should this user be in?", such as warehouse, AP clerk, Purchasing
buyer, etc. Then we assign them to that group in their User Profile, which
has a menu assigned to it, and we are done, for most new users. I think this
is a common approach. We e-mail I.T. and say "put John Doe in group XYZ", so
there really is no form because that is all the data needed.
If the user does not fit in an existing group, we say "what group is he/she
closest to?" in terms of need for access to programs, then make a list of
modifications to the Security Workbench settings for a copy of that "closest
group" which are needed for this user. So I.T. creates a new user group,
assigns the person to it in User Profile, copies the Security Workbench
settings for the "closest group" and makes the changes per the list of mods
We have (most of) the security settings in an Excel spreadsheet, on the
jdelist Forum at Downloads called Security Settings by Programs and User
Groups Spreadsheet, where W (write) means application security = Y, R
(read) means action set to N for OK/delete/copy, N (no access) means
application security = N, and RR is for R (report/UBE) programs and means
"run report" thus application security = Y.
So I can send an e-mail to Gwen in I.T. and say "please set up Tom Cruise in
a new group, like Gendisplay group with changes of P4310 = W, P4312 = W,
P4101 = W", add the new group to the security spreadsheet and make the
listed changes, Gwen does Security Workbench per the e-mail (copying the
specified group and making changes is much quicker than keying all 1200
lines from scratch) and we are done. I save the e-mails and we have a record
of all changes and new folks and new groups.
You could do a form with data of: date, name, group to assign to, new group
required Y/N, group to copy and modify, mods (with a list of: program
number, action security settings Y/N for OK, Delete, Copy, etc.), and any
special things list Processing Option security.
For a few programs, like P4310, we have security by form (e.g. W4310A).
Lead people (power users, section honchos) have write access to processing
options. All users have read access to processing options. Menus control
access to versions. Leads have Fast Path.
If someone writes a new R report, we have a form specifying what user groups
get access to the report. I can send you that one if you want. E-mail me
David, won't you end up having a ton of groups defined, if you assign a new
group for every user who runs a specific application from the rest of the
users in his/her current group. I like yourself have applied a number of
user groups but I would slot the new application into one of my predefined
groups and/or in the groups with a higher security level above. I will only
create a new group if it is absolutely necessary.
Crawford: Agreed. Put everyone into an existing group where possible. When
set up a new program or report, add it to all groups where needed. Creating
a new group we have found is seldom necessary. Most of the time, it is only
necessary when we do something new in OW (infrequent) and new people in a
new section start using OW and their needed access does not look like
anybody else's. We have 16 groups including the IT folks, which covers GL,
AP, job cost, fixed assets, inventory, purchasing.
We have 1, 2 or 3 groups for a given area. Example: 1) warehouse worker, 2)
warehouse office people who have write access to more stuff, and 3)
warehouse lead who has the whole shooting match for inventory programs, and
GL post for her batches. AP has 3 levels/groups. GL has 2 levels. Fixed
assets and job cost has 1 and nobody has blown things up (amazing).
We have a Gendisplay group for all users who are not in some "enter
transactions" group. So this is lots of folks. They can look at stuff
(action security set to N for OK, delete, copy) for all programs they might
reasonably want to look at, and all else for them is set to N for
application security. We use *Public, *All = No, which has actually been 98%
workable (infrequent screaming, and then we fix it), even though Howard
Clodfelter at JDE said don't do it.