Bedework Calendar System 3.5

Bedework version 3.5

Last modified: June 24, 2009

http://www.bedework.org

Introduction

Bedework System Overview

Bedework History / Background

Calendaring Overview / Standards

Bedework In Action: Case studies

Getting Started

(stuff from ch 2 of current manual, updated)

Deploying Bedework

prerequisites

installation

(all stuff from ch 3 of current manual)

Upgrading

Performance & tuning (ch 4 of current)

Access control (ch 6)

tutorial: installing Bedework on Linux with MySQL

Bedework theming (design guide)

Integration with the enterprise

directory

portal - Bedework and Portals (ch 5 current manual)

mail

other calendar systems

Public Events Calendaring

Overview: The event pool model

planning your Bedework system

public calendar organization

managing users

managing calendars

managing calendar suites

managing events

Getting events in

Administrative web client

Community submissions client

Getting events out

Calendar suites

data feeds - ical, raw xml, rss, json, js, etc.

Filtering

Adding custom properties (X-Properties)

backups

Personal and group calendaring (much of this is in chapter 7 of current manual)

Overview

personal and group calendar organization

The user web client

CalDAV clients - Lightning, iCal, etc.

Subscribing to public events

Scheduling Meetings

Calendar sharing & subscribing to other user events

Other features

Timezones (ch. 8 current)

Bw and CalDAV (ch. 9)

Bw and CardDAV

Other features (ch 10 current manual)

Temporary stuff:

MOST OF THE FOLLOWING NEEDS TO BE REPURPOSED FOR LATER CHAPTERS OR REMOVED

Views

Views are named collections of subscriptions. They are of most use in the public events system though they are used in personal calendars. Public events administrators can create a number of views. Typically they are used to group together subscriptions are to hold all subscriptions (as in an “All” view).

Public Events Calendaring

Illustration 1: public events The point of a public events system is, in general, to disseminate event information to the widest and most appropriate audience possible. It is important that the public events are easily navigable and straightforward to find, subscribe to, and create. To achieve this, the calendar tree should be topical, consisting of high-level aggregate categories such as “Arts”, “Lectures”, and “Athletics”.

Illustration 1 shows an example calendar structure for public events. Noticeably absent from the tree are folders named by organization or department. As we have learned in web information architecture, users should not need to know what group within an organization's hierarchy sponsors an item to find it. However, an organization should still be able to pull a “departmental” view of the calendar information and present only that to their intended audience: this is the purpose of Calendar Suites. These are used to display a customized and filtered view of public events, but are not intended for group calendaring – which takes place within the Personal & Group calendaring space.

We believe the most flexible architecture for delivering public events is to create a large central pool of events organized by topic and to draw from this pool both for individual user and departmental access. Users who are interested in all lectures across your enterprise will be able to subscribe to a single source for these events, while departments may display only the lectures sponsored by them from the central pool.

As stated above Bedework's calendar trees are divided into folders and calendar collections. Only calendar collections may be added to folders. Events may only be added to calendar collections. In Illustration 1, it would not be possible to add an event to the root “Arts” folder; rather, an administrator must decide to which art calendar an event belongs. To keep this decision making process from becoming onerous, calendar collections within the top-level categories should be course-grained, keeping the selection of appropriate calendars for events as simple as possible.

Public Event Administration: Users & Groups

Groups:

In Bedework's current system, 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 “event 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 may in time (such as managing group membership).

Group1 admins group owner, e.g. “douglm” B event owner, e.g. “agrp_Group1” Illustration 2: Group Structure

The event owner is a user, not found in the organizations 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” who's preferences define the behavior of a calendar suite. The system ensures that these event 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 event owner so that administrators can only see and edit events for their current group.

The super user(s) can switch to any group making all events available.

In addition, if the system is appropriately configured, locations, contacts and categories are also filtered making them editable only by the group. They are however, always readable. The other extreme of having no editable locations, contacts and categories has been requested and something near that can be achieved by creating them in a special group. The intent is to create locations so that they conform to a particular code of practice. Not allowing administrators to create locations at all may become a problem when events take place off campus.

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. Unlike calendars, groups are organizational, e.g. “Arts”, “SOE” (school of engineering), or “Athletics”.

While it is possible to close branches of the /public sub-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 “departmental” calendaring (group calendaring) 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 ok for others to see). These should be kept in the personal 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 users:

To add an administrative user 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).

Once in the system, an administrative user may be given roles from the “Manage public event administrators”menu item under “User management”. The current meaningful roles are 'super-user' and 'publicEvent' administrator. The publicEvent role allows write-content access to the /public tree (assuming the user is in a child group of the top-level campusAdminGroups and the ACLs are not changed); the super-user role allows full access to the Bedework admin client.

Authentication

Authentication is not managed by the Bedework system internally, but by the servlet (or J2ee) container (see section 2.4, Authentication). Administrative roles and authentication are separate; a user who can authenticate, but who is not an administrative user, will see a “No Access” message upon logging into the admin client. A user who has been added as an administrator but who cannot authenticate cannot log in at all. Both conditions – authentication and authorization – must be met for administrators to work in the admin client.

Calendar Suites

The intent of calendar suites is to provide a customized view and appearance for significant groups within an organization, such as a school or large department. A calendar suite is associated with an administrative group which has an event owner (an internal bedework account) whose preferences are used to set up the skin, default view, view period, views and subscriptions.

Personal & Group Calendaring

Personal and group calendaring is the second calendaring space provided by Bedework. It is the realm of desktop calendar clients, personal schedules, shared calendars, meetings, invitations, to dos, and so on. Much of the calendaring standards focus on this aspect of calendaring, and there are many commercial examples in this space (e.g. Microsoft Exchange with Outlook).

Many of the mechanisms used by the personal calendars, such as preferences, views and subscriptions, are also used by the public user clients to configure their appearance. The major differences between public and personal events lie on the way events are shared and access is managed. A further major difference not fully handled in this release is the need for multi-language support in public events, a need nowhere near as pressing in personal and group calendaring.

Personal calendars also have the problem of interacting with external clients and handling events generated elsewhere, for example through meeting requests.

The personal calendar space is rooted of the main user calendar, named by default “/user”. (these names can be configured at build and deployment time to be more appropriate for non-English speaking institutions.)

Below this is a folder for each user of the system for which there has been some activity. Unless an organization chooses to build some form of feed, users who have never had meeting requests and have never logged on will have no presence in bedework. Their user calendars will be created automatically the first time an event is sent to the account or they log on. Personal calendaring is dealt with more fully in Personal Calendars – Page Error: Reference source not found

Arlen Johnson

2009-06-19T14:54:28.67

Arlen Johnson