Admin Package RFC

Site administration tasks such as permissioning, bulk mandatory notifications, and navigation to admin areas are cumbersome or unavailable. They are thrown together into the acs-subsite package when they should be offered in their own package. 

(DAVEB The admin pages are in acs-subsite for a good reason, I think. They are tied to each subsite, so you can manage the administration of a single subsite. Now that it is possible (although maybe not easy quite yet) to define a subsite install with pre-defined packages underneath it, it would make sense to split out the admin to a separate package which could be customized).

This wiki will allow interested contributors to offer suggestions along the lines of an Admin Package. This package may only actually be a series of patches applied to existing packages; or it may be a new package altogether.  Since most of the functions themselves already exist, this package will most likely consist of consolidating or calling existing code, and cleaning up the UI.
 

A New Kind of Administrator

The Site Administrator for OpenACS may have originally also been the package developer and the system admin. But now clients are taking on the role of subsite manager. Tech neophytes are granting permissions, mounting new packages and approving members. This is especially the case in Non-Profit organizations using OpenACS on a limited budget. They just can't afford to pay their vendor to admin the site. So they ask us to teach them how to do it.  Thus the context and identity of the Administrator has changed, requiring us to raise the bar on usability for all major Admin functions.
 

1) Notifications

Notifications for OpenACS were developed under it's web community context to allow only users to sign up for their own notifications. In a corporate environment or a setting in which members are required to receive certain e-mails, bulk subscription is a requirement. For instance a web company which uses bug tracker to manage change requests will create a subsite for each client with a bug-tracker under each one. Then the administrator will have to sign the user up for notifications manually, every time. The preferred functionality would allow one initial sign up of a group to notifications for a logger application. Then all subsequent members joining the group would be automatically signed up for notifications.

Victor Guerra has patched notifications with user and group subscription functionality which works quite well. But it is still tied to the package. A single interface for all notifications spanning *across* subsites is necessary.

• Subscribe/Unsubscribe individual users and groups to notification to package notifications.

 

2) Permissions Management 

Administrators routinely work with users, groups and application permissions, but these are spread out across the site. Site wide permissioning tasks such as granting 10 applications in a subsite different permissions is extremely tiresome requiring multiple navigation clicks to navigate from permission screen to permission screen. The genius of the OpenACS permissioning system is obscured by a poor UI. A single interface for permissions would make large admin tasks like this much easier.

• Grant/Revoke any privilege on any application on any subsite
• Easily navigate around subsites via a tree

 

3) Group Management

Admins must be able to view which groups a member belongs to, and be able to remove that member. This feature already exists. In addition, admins must be able to easily:

• Add a member to any group from that members detail page.
• Manage a related group's membership and properties.

 

4) Member Management

 

/acs-admin/users/ is a good search tool for maintaining members, and it is available through a developer support link, but it is not implemented on the Members list where it might be used most effectively by administrators and non-administrators with member list access. Also site administrators cannot rely on developer support as they may not have  permissions.  On the members page admins should be able to search for a user via an AJAX lookup field by name and e-mail address. We can borrow this from FreeMED. Once a member is selected, the member screen available to admins listing notifications, permissions, group memberships and the existing links in /members/one.tcl will appear.

• Add subsite membership buttons to Membership detail page (Invite, Remove, Ban)
• Join member to any group

Developed under the subsite model,  many UI and human interactive features satisfied local subsite requirements, or the requirements of very small sites. As OpenACS expands, the UI must accommodate the desire of site wide administrators to notify, permit and manage users anywhere on the site.

 

5) Site Map and Subsite Applications Redundancies

The Site Map and the Subsite Application tab are redundant pages.  Both split the site tree, node mounting, adding deleting, and renaming. This should be under a single interface, probably using the Site Map UI (or a better Tree UI).
 

Objects, Interactions and User Interface 

Members, Groups, Notifications and Permissions interact in the following ways to give us our ideal UI: 

(Image no longer exists. Original url: http://openacs.viscousmedia.com:8080/files/view/Objects.gif )