It's important for Sloan that the default setup remain that these options are all available to all class and community admins.  This functionality was one of the biggest selling points/wins for the system at Sloan because it gave faculty the autonomy they needed to run their courses and gave communities that same flexibility, especially since many have non-MIT members.  And, for the Manage Membership link, since any member can drop any membership, but not rejoin a closed group, it's important that the group admin be able to add people back in.  The more groups you have, the more adminstrative burden is placed on the site wide admin to monitor, without any tools, the actions of users.

I don't understand exactly what you mean by your last question - can you provide an example or two of this in action?

DeeDee

I understand what your needs are, and my suggestion is not to eliminate those functionalities, rather than that, I would like to see a parameter that will allow for an entire .LRN installation (all the classes) to allow or not those actions. In our case is quite important since we don't want those, specially the one for allowing professors to add users to a class, since we do that automatically (add users to groups).


>>Also, there's a need for a dotlrn-admin users, that means, the dotlrn-admin might not be a site-wide-admin, any suggestions on this?

My user scenario is this, we might want to give to some people dotlrn admin priviledges, but to site wide admin, in other words, a dotlrn admin should be able to create class and that kind of stuff, but not be able to install a new package ....
(any technical suggestions on this??)