Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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.

...

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" “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" “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_.

...

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"“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" “Arts”, “SOE” (school of engineering), or "Athletics"“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.

...

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 “Access rights and groups" 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

    Note
    iconfalse

    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.