From: clayton c. <cc...@ca...> - 2001-05-01 16:08:18
|
Todd, good to hear from you. i was about to fire up a "call to action" email before i saw your post. > *Users table will be minimalistic absolutely ! > * User_space and Group_space will be flat. > A flat groupspace enables any user to be a member of any group. This is > great until you only want a subset of the Physics Dept (group) to be > moderators on Physics Dept announcements. I decided that instead of FORCING > a group tree hierarchy, I would let the individual site administrator make > sure that only Physics group member were in the Physics-moderators group. this can be simplified by allowing roles on the group membership table, which to me is a necessity anyway in the cases your envisioning. in the Physics Dept, for instance, i want to be able to set permissions on different activities based on whether a person is Chair, Faculty, Staff, Student or Moderator (administrator). the ACS code i ported accomodates this, though i can probably simplify it a bit. more comments below ... another idea that may make the administator's job easier is a group membership queue with 1 click approval on the admin side. that way anyone can try to join, but they're only in if approved. this can be made optional, too. > Groups table: > group_id INTEGER primary key > name VARCHAR(32) > parent_id INTEGER [foreign key to group_id] > [root has same group and parent id] or parent_id == NULL > > group_membership table (matrix): > group_id INTEGER [foreign key] > user_id INTEGER [foreign key] > index on group_id > index on user_id > index on group_id, user_id > [speeds up membership searches significantly] i think we should support roles for the reasons mentioned above. this should help mitigate the effects of a flat user-space (at least as it relates to group). as explained above, it allows more natural expression of other core processes (access control/security and task partitioning, etc). im trying to get an app out the door, but i'll post more as time permits. clayton |