Before I get started with my $.02, let me point out that although I
can influence decisions regarding new features, that this message
should not be misconstrued as a indication to do so or as a guarantee
of groups within groups in a future release. \*end disclaimer*\
My concern regarding groups of groups has been loss of control of the
big picture by the person who owns a group that contains someone elses
group. For example, lets say I have a group
% pts mem pierette:co-workers
phil
cindy
linda:co-workers
kt
mary
alan
kt:people
keith
jeff:friends
etc
etc
By putting linda:co-workers into my group - I effectively gave some
administrative control of my group to Linda, who *later* added the
group kt:people to her own group ...... effectively giving some
adminstrative control of my group to Katie. Linda is probably unaware
of the fact that by modifying her group, she's also modified mine -
and she really shouldn't *have* to worry about it. Jeff probably has
no idea that his friends are becomming my co-workers and I'm likely
unaware of this too.
So if used by "normal" users, groups within groups may quickly become
a real quagmire. How do you adequately warn naive users of this phenomina?
I'm not convinced they'd think of it themselves (after all, none of
the experienced users on this list mentioned it.)
One may argue that the ability to place groups in groups should be
limited to system:administrators, but on the scale that UMich is
discussing, I think that would be an unacceptable limitation.
Consider this for a solution.
For non system:adminstrators, groups can only contain groups that are
owned by the same "person". Ie, I can have this setup
% pts mem pierette:people
pierette:managers
linda
kt
pierette:co-workers
pierette:training
pierette:documentation
pierette:afs-developers
pierette:friends
More importantly, the History department at UMich can have
% pts mem history:folks
history:faculty
sue
chan etc
history:students
history:undergrads
bob
nancy etc
history:grad-students
george
mcintyre etc
And, the sys admins at Umich can put any group into any group, so
knowing that the only members of the prefixless group "history" are
the department head and their administrative assistant, they feel
confident that all the history groups (and math groups, and chem-e
groups, etc) are well managed. So they (the sys:admins) make groups
like this
% pts mem Umich:people
humanities
history:folks
english:folks
etc
engineering
chem-e:folks
ee:folks
etc
% pts mem Umich:faculty
history:faculty
english:faculty
ee:faculty
etc
Now I haven't even begun to look at the code to see how feasible this
is. And there are certainly things to be considered, such as the
effect of a
% pts chown pierette:friends -owner david
and how that would effect the group pierette:people
There is clearly a strong desire for groups within groups, and at this
stage many of you may be so enthusiastic about the benefits that you
may be willing to overlook the "loss of control" problem that my
afflict your naive users. Maybe it's not nearly the problem that I
fear it is. Nonetheless, I'm out there fighting for the little guy,
Joe Freshman, who finds out through some weird twist of groups w/i
groups that his worst enemy is reading all his personal files because
joef:best-friends
is more that he ever expected or planned it to be.
Now imagine this happening to Joe T. Professor (T is for tenured!).
Pierette VanRyzin
AFS Training
