BW 3.8 Add admin groups and users

Introduction

Administrative groups are hierarchical and inherit access rules down the group tree.  In the public events system, all admin groups are children of a default root group named campusAdminGroups and inheritance of access control rights starts from there.

Calendar suites are attached to groups.  An event administrator will add and edit events in the context of the calendar suite that is found first when traversing back up the tree.

Public events are administered centrally through the administrative web client. Every administrator is a member of a group, and events are owned not by administrative users directly, but by a special "events owner" associated with the group.  Each group also has a group owner that is a specific administrative user; this role does not currently provide any functionality, but allows you to specify the lead event admin for a group.

The events owner is a Bedework system user, not found in the organization's user space, that owns all the events for a group. Having such an owner allows all group members to see and edit events within the group.  Also, the event owner is the "user" whose preferences define the behavior of a calendar suite. The system ensures that the events owners are distinct from real users by prefixing them with a string, by default agrp_.

Within the administrative client, events are filtered by the current events owner so that administrators can only see and edit events for their current group.  A super user can switch to any group.  By searching for events in the admin client, event administrators can also tag events created by other groups.

If the system is configured to do so in the configuration properties files, locations, contacts and categories can be filtered to make them editable only by the group. They are however, always readable. Creating contacts and locations that cannot be edited by typical admins can be achieved by creating them in a special group.

Group structure and access control

Access control is inherited from the top down the group tree. Therefore, it is best to create a single, top-level group for access to /public and then add all other administrative groups to it. By default, Bedework comes with a top-level group named "campusAdminGroups". All other groups should be made members of this group to inherit write-content access on /public.  Groups should represent the departments within your organization who will be responsible for adding and maintaining public events, e.g. "Arts", "SOE" (school of engineering), or "Athletics".

The first children of campusAdminGroups should be groups associated with calendar suites.  By convention, we name these groups calsuite-SomeName to distinguish them from typical admin groups.

While it is possible to close branches of the /public calendar tree from access to all administrators by creating a different group hierarchy, we discourage doing this. If public calendars are kept topical, an administrator from any group can add events to any calendar in the tree.  However, an administrator can only see events created by his or her group. 

It is important to remember that group calendaring (e.g. scheduling meetings within a department) should be kept away from the /public tree – which is only intended for public events. Events that must not be seen by any but a subset of your community are not public (such events are to be distinguished from those intended for a subset of your community that are still okay for others to see). These should be kept in the personal and group space, or if your need dictates it, in a top-level /dept branch of the tree which you will need to create. We believe in actual practice, most group calendaring will best be managed within the personal and group space.

Administrative groups are stored in the calendar database. Administrative groups are intended to be separate from user groups to allow different access rights to be defined for administrative users. (See "Access rights and groups" below)

Add administrative groups

1. In the Administrative Client, choose the Users tab, then click on Manage admin groups.
2. Click on the Add a new group button
3. Fill in Name, Description, Group owner (typically /principals/users/admin), and set the Events Owner to /principals/users/agrp_groupName where groupName is the same string you used in the Name. 

   The prefix agrp_ should be left on event owners; the prefix is defined in your configuration, in the cal.properties file.  Look for org.bedework.app.CalAdmin.admingroupsidprefix.

Add calendar administrators to administrative groups

To add an event administrator to the system, simply add the user to a group. When a user is removed from all groups, the user will be removed from the system. Because the public event space is distinct from the personal calendaring space, administrative users are managed in Bedework's database by default (though they need not be)

1. In the Administrative Client, choose the Users tab, then click on Manage admin groups.
2. On the line that begins calsuite-MainCampus, click on membership.
3. Add superusers, one at a time, in the Add member: box, making sure that user is selected to the right, then click Add.

Add superusers

1. In the Administrative Client, choose the System Tab, then click on Manage system preferences
2. Add users to the Super Users field.  The field accepts a list of comma separated user ids.  
3. In most cases, you'll want to add your superuser to the group from which your calendar suite is hung, in this case calsuite-MainCampus.  Choose the Users tab, then click on Manage admin groups.
4. On the line that begins calsuite-MainCampus, click on membership.
5. Add superusers, one at a time, in the Add member: box, making sure that user is selected to the right, then click Add.