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