Bedework Enterprise Calendar System

The Bedework system supports both personal and group calendaring and scheduling and public events.

Introducing Bedework

Bedework is an open-source enterprise calendar system that supports public, personal, and group calendaring. It is designed to conform to current calendaring standards with a goal of attaining strong interoperability between other calendaring systems and clients. Bedework is built with an emphasis on higher education, though it is used by many commercial enterprises.

You may choose to deploy Bedework for public events calendaring, personal calendaring and scheduling, or both. Bedework is suitable for embedding in other applications or in portals and has been deployed across a wide range of environments.

1. Overview

1.1. Features of Bedework

Java: Written completely in Java, Bedework is system independent. This version compiles and runs in Java 11.
Standards based and interoperable: Interoperability with other calendar systems and clients by way of standards compliance is a fundamental design goal of the Bedework system. The following standards are supported:
- iCalendar support (rfc5545)
- iTIP (rfc2446)
- CalDAV (rfc4791)CalDAV scheduling (draft)
- CardDAV v.4
- VPoll (draft)
CalDAV server : a full CalDAV server is a core feature of Bedework. It can be used with any CalDAV capable client and has been shown to work with Mozilla Lightning, Apple’s iCal, Evolution, and others.
CardDAV server : Bedework provides a CardDAV server providing personal and public contact stores for use in the personal client. A stand-alone JavaScript address book application is included with the personal web client suitable for deployment in other web applications such as email web clients.
Web clients :The Bedework web clients provide access to public events in guest mode and to public and personal events in authenticated mode. All web clients are easily skinned allowing a high degree of customization.
Public calendar suites: Public events are displayed using "calendar suites" allowing multiple organizations to maintain their own public views of events with whatever degree of visibility is appropriate. A Bedework public calendaring installation may have one or many calendar suites. A calendar suite provides a customized view of events, custom theming, and control over how events are tagged by event administrators.
Public calendar feeds and embeddable JavaScript widgets, supporting ical, jcal, xcal, json, and XML.
Personal calendars: Bedework provides a web client for personal and group calendaring including scheduling. Using CalDAV desktop clients, users can see a fully synchronized view of their personal and subscribed events between their desktop client and the web client.
Administrative client for public events: Public event entry and maintenance is carried out through the administrative web client. The system supports three roles: Super Users control global system settings including user and calendar maintenance and the setup of calendar suites. Calendar Suite Owners can modify the settings of their calendar suite, and Event Administrators can add and edit events for the administrative groups to which they belong.
Public event community submission: Bedework provides a web client for submitting events to a public queue allowing members of your community who are not event administrators to suggest public events.
Public events registration: Bedework supports registration for public events with waitlisting, registrant caps, and notifications. Custom registration fields can be built and reused for any registerable event.
Account Self-registration: This client allows users to register for a Bedework calendar account to register for events or other features.
Highly customizable look and feel and standards based: The web clients are themed using CSS and a theme settings file, or by deeper manipulation of XSLT. Designers can theme Bedework for multiple clients and uses, without involving your programming staff. Bedework comes with skins for producing the web clients, data feeds, and displays suitable for handheld devices. Bedework provides a widget builder that makes it easy to embed dynamic event listings on static web sites.
Database independence - Hibernate : The core of the calendar uses Hibernate for all database transactions giving support of many database systems and enterprise level performance and reliability. A number of caching schemes are implemented for Hibernate including clustered systems giving further options for improving availability.
Sharing : Full CalDAV access control is available allowing the sharing of calendars and calendar entities based on authentication status and identity.
Scheduling : Bedework supports scheduling of meetings including invitations and their responses. Caldav scheduling (still in draft) is supported. Freebusy is supported and the busy time is displayed as attendee lists are built. Access control allows users to determine who may attempt to schedule meetings with them.
Import and export : Events can be imported and exported in iCalendar (RFC2445) format. This provides an option for populating the calendar from external sources. A dump/restore utility provides a means to backup and restore xml data files.
Calendar subscriptions : Users may subscribe to calendars to which they have access, including public and personal calendars. iCalendar data feeds are available from the public web client.
Multiple calendars : The core system supports multiple calendars for users and for public events.
Tagging & Filtering : Events and folders can be tagged by any number of categories and event views, feeds, and widgets can be filtered by these.
Internationalization : Bedework supports full internationalization, including multilingual content (though multilingual content creation is not yet exposed in the web UI).
Data feeds: Bedework produces RSS, Javascript (e.g. json), iCalendar, and XML feeds. Custom feeds can be developed by writing an XSL skin. Feeds can be filtered by category or creator, and a feed and widget builder is available to help end users and developers design public feeds and embeddable event widgets.
Portal support : Bedework has been shown to work as a JSR168 portlet in Jetspeed, uPortal and Liferay using the portal-struts bridge.
Timezone support : Full timezone support is implemented. There is a set of system defined timezones based upon externally available sets of timezone definitions. In addition users are able to store their own timezone definitions.
Recurring events : Extensive recurring event support is available via CalDAV and the web clients.
Event references : Users may add public event references to their personal calendars. Event references can be annotated by the user.
Pluggable group support : Bedework uses a pluggable class implementation to determine group membership for authenticated users allowing organizations to implement a class which uses an external directory. The default class uses internal tables to maintain group membership. Different implementations can be used for administrative and personal use allowing the separation of any given users roles.
Container authentication : There is no authentication code in Bedework. Rather, Bedework behaves as a standard servlet, and all authentication is carried out through external mechanisms. Standard container authentication (via Tomcat or Jboss) and filter based Yale CAS authentication are used in production. The quickstart comes packaged with the Apache DS server against which the quickstart deployment of Bedework authenticates. This server can be used in production, though many deployers opt to authenticate against their organization’s existing directory.
Support for other calendar systems and clients : It is possible to access an entire calendar with a single url. This can be used to subscribe to a Bedework calendar from Google or Outlook. Bedework can also take advantage of the richness of CalDAV capable desktop clients such as Apple’s iCal and Mozilla Lightning.

1.2. Release Notes

1.2.1. Release 3.13.1:

There was long standing a bug in category handling for updates. An attempt was made to preserve default categories for calsuites when an event is updated. For example if an event is suggested and accepted the accepting calsuite has its default category added to the event.

This code was being applied to collections which made it impossible to turn off a default category added to, e.g. an alias, by mistake.

This release also introduces a new authenticated public context. This is intended to be used for departmental calendars for example. There were a number of changes needed to make this work but most of the work will come in setting up the calendar collections and aliases. Documentation and examples will follow later as always.

Drop the explicit reference to maven profile bedework-3 in the bw script. Fix that script to allow -P <profile> and use that in the install script to use bedework-3
This allows us to specify a default profile that differs from the bedework-3 profile.
Additionally - add support for a .bw file in the user home which allows setting of the profile. See Default Maven Profiles
Wildfly galleon installer 4.0.3.Final stopped working soon after the last release. Updating to a later version and hoping this won’t break.
Updated google maps url generation to use location combinedValues property
If the location map url is "NO-LINK" (without quotes) then no link will be generated.
Remove BasicHttpClient. This necessitated some config changes -
- authCardDav.xml and unauthCardDav.xml in bwengine now have a url rather than host, port and context.
- notify/notify-config.xml changed - removed host, port, context. Added URI
Web client changes
- Change how we select the mode of working -
- Config for user and submission clients require new entry - <readWrite>true</readWrite>
- Add a new authenticated public client. This should allow limited read-only access to views of the data. Users will be added to admin groups to control the access.
- Removed bwapptype parameter from web.xml files. Value is duplicated in client configs.
Bug fixes
- User TermsFilterBuilder for collections. Was generating partially working query
- change "|" to " or " in xsl - was not encoded - broke some pages
- Problem related to timestamp handling was causing ES version errors.

1.2.2. Release 3.13.0:

This release mostly consists of upgrades to almost the latest ElasticSearch (always a moving target), the currently latest wildfly and to Java 11 the current LTS release.

Installing the quickstart requires that you first install docker if you wish to have a quickstart image of elasticsearch installed.

There have additionally been some minor changes in configuration and the addition of a tool feature to help in calendar suite creation.

Beyond that there is very little functional change since the last release. However, note that the move to the latest ES required a complete rewrite of the query and indexing modules.

Upgrade to ES 7.2.0
Upgrade to wildfly 17.0.1.Final
- Use galleon to install - allows updates
- Don’t use wildfly modules for deployed ear dependencies.
Require java 11.
- Many changes to build. Much of the XML support is removed from java core.
- Updates to maven plugin versions
Minor changes
- Add an error log handler
- Reduce noise in logs
  - Remove bogus elements from config files
  - Remove ldap group member so we don’t get annoying error messages
- Add auth user update to cli tools
- Fix NPE when editing auth user that doesn’t exist
- Some fixes for travis build

1.2.3. Release 3.12.7:

Fixes to install script
Library updates
- Update http version to avoid security issues
- Add missing dependencies to eventreg
Add tzsvr data to quickstart
Changes to tz conversion - still broken
XSL fixes - missing approots
Client
- Remove empty x-properties on event update
Log processing
- Was missing log prefix in parser
- Add more checks for same task
Deployment
- Use deployment base
Sync
- Use last-modified if etag not present
Watch for null x-properties in event list. Can be caused by deleting them in db.
Indexing
- Don’t index x-properties - can be large

1.2.4. Release 3.12.6:

Library updates
- Update servlet api version
- Update jackson version to avoid security issues
- Update http client version to avoid security issues
Log analysis
- Updates to generated figures and some analysis of access logs
Sync process
- Update category prop updater to fix NPE
- Add callback method to fetch location by combined value. Use it when updating or adding an event.
Indexing
- Fix location mapping - was missing combined field.
Install
- bwcli wasn’t being built by install script
Restores
- Restores were failing because the fake event property calpath code was getting an NPE - no principal. Fixed it so principal isn’t needed. Caused cascading updates up the stack. Dropped the principal object where possible. Generally only need the href.
- Resource content handling was broken in restore. Should just set the byte value and create the blob when we have a session
Client
- Add action to clear any principals notifications
- Fix feeder main/listEvents action - now works
Others
- Svci pars wasn’t handling the readonly flag properly. Worked for unauth but wasn’t turning on readonly for authenticated methods.
- Drop loader-repository elements from (some) jboss-app.xml
- Better error messages when building index docs and in AccessUtil
- Watch for null home in CalSuites
- Response: Add method to set Response status from a response

1.2.5. Release 3.12.5:

Logging
- Add a bunch of jsonIgnore to the Logged interface to stop the fields turning up in json.
- Fix error methods. Use exception message as first param.
Client
- Cache default filters for ro client. Use calsuite as key
- Cache user collections in session. Use calsuite group as key
- NoopAction extended MainAction. Should not as it retrieves a lot of unused data.
- Make session timeout for /cal and /soedept configurable and default to 5
Don’t store collection in BwCollectionFilter. Was never used. Just store path as entity
Fix FlushMap in utils. Current fetched value was not discarded.
Fix bw script - was missing some of the newer modules
BwLastMod:
- Add JsonIgnore to getDbEntity or we get a loop.
- Set the db entity when we clone or we get an NPE

1.2.6. Release 3.12.4:

Fixed a few bugs.
- BwResourceContent bug below
- Suppress a request-out log message unlesss really on way out
- Index wrapper type for calsuite - not calsuite itself
- Try to force refresh after adding calsuite
- HttpUtil POST produced Accept rather than Content-type
- Bad forward in add calsuite produced bogus error message
Updated log analyzer so results are easier to read.
Factor deployment modules out of bw-util into new bw-util-deploy

1.2.7. Release 3.12.3:

Added new cli command to analyze log data.
Add new REQUEST-OUT log message for analyzer
A number of bug fixes
- Touch collection on update of acls - was not getting indexed
- Calling wrong indexer to update resource content
- Wasn’t saving entity in response from indexer
- Add cache to SvcSimpleFilterParser so we don’t repeatedly attempt to fetch children of collections.
- Should be returning an empty array when the event is not found
- Was calling wrong method to fetch location for update

Note: A bug was discovered almost immediately. The commit is at https://github.com/Bedework/bw-calendar-engine/commit/c83e77e3f5ceb990029b84ca7440af83fdc4e568 and a patch:

Index: bw-calendar-engine-facade/src/main/java/org/bedework/calfacade/BwResourceContent.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- bw-calendar-engine-facade/src/main/java/org/bedework/calfacade/BwResourceContent.java	(revision b248db13b030a73828d7b8c9428dda9ebf262a0c)
+++ bw-calendar-engine-facade/src/main/java/org/bedework/calfacade/BwResourceContent.java	(revision c83e77e3f5ceb990029b84ca7440af83fdc4e568)
@@ -187,14 +187,11 @@
       while((len = str.read(buffer)) != -1) {
         b64out.write(buffer, 0, len);
       }
+      b64out.close();

       return new String(baos.toByteArray());
     } catch (final Throwable t) {
       throw new CalFacadeException(t);
-    } finally {
-      try {
-        b64out.close();
-      } catch (Throwable t) {}
     }
   }

1.2.8. Release 3.12.2:

Added new cli command to allow refresh of tz data.
Widespread changes to remove references to log4j. All localized in one source file (and a few poms for runnable code).
Use asciidoctor to generate this document.

1.2.9. Release 3.12.1:

Searching for contacts/locations

In the admin and event submissions clients replaced simple drop down with a search interface. Requires back end support for the search )a restful style with json response).

ES only read-only clients.

Implement an ES only read-only interface. The public client can be built without any hibernate support as it doesn’t interact with the database. This required at least:
- Minor API changes
- Indexing of more entities - principals, calendar suites, preferences, filters.
- New core interface implementation which only handles the read only methods.
- Refactored the core to remove a callback. Also to spilt off the read only code.

Split out ES indexes

Significant change to indexing to try to resolve the contacts issue and prepare for upgrade.
ES v7 will allow only one type per index. To prepare the index was split into many. Requires a doctype parameter to be added to most calls, significant changes to the (re)indexing process and other associated changes.
Almost all calendar engine classes were affected in some way - mostly relatively minor.
Configuration changes: no longer have a public/user calendar name. The location of the mappings is a directory - not a file and there are multiple mapping files under directories named with the lowercased doctype name.

Use ES only read-only interface for CalDAV read-only methods.

The hope is this will provide a significant performance improvement for those methods.

Other changes.

Merged pull request from viqueen. Deal with DAV security issue.

1.2.10. Release 3.12.0:

Move to github/maven

A number of modules have been replaced with their github/maven equivalents from the 4.x branches. Other than changes for the build process these modules are functionally equivalent. This change was initiated to make some module classes available for externally built plugin modules. The 3.x modules and their 4.x replacements are:
- rpiutil → bw-util
- bwaccess → bw-access
- webdav → bw-webdav
- caldav → bw-caldav (bwcaldav is the bedework implementation of the interface)
- bwxml → bw-xml
- eventreg → bw-event-registration
- selfreg → bw-self-registration
- synch → bw-synch
Related changes were to build the runnable post-deploy app in bw-util-bw-deploy and run that. Some configuration properties had to be changed to align.
Having done the above the master on github for the calendar engineand client is now the current 3.x dev version, there is a 4.x branch for future development and release branches will be created as necessary.

Related to maven/github switch

The urls for wsdls is changed. e.g. /wsdls/synch/wssvc.wsdl becomes /xmlspecs/wsdls/synchws/wssvc.wsdl. This necessitates changes to configurations:
- synch/../orgSyncV2.xml
- synch/../localBedework.xml
- bwengine/synch.xml
- bwengine/system.xml
- eventreg.xml
Yet more refactoring was needed. Turns out we had an unbuildable set of modules with bw-xml depending on bw-util for the deployment. Broke out the 2 modules with a dependency on bw-xml as bw-util2
Moved all the xsl into it’s own module - bw-calendar-xsl. Thi salso needs changes to configs - all xsl url paths are now prefixed with /approots - the context at which the xsl is deployed. Look for elements appRoots and browserResourceRoots in the configs

Scheduling

Fixes to scheduling code to try to ensure pending inbox events get deleted
Updates to iSchedule client for later version of httplient. Moved some code out of caldav tester into common utils

Notifications

Fix the listeners so they close down without exceptions

Websockets

Add code to support websockets for a new experimental streaming protocol (a CalConnect initiative)
Many changes to build process - wewbsockets applications cannot be inside an ear file. Now possible to deploy as a standalone war. Websockets endpoint is now a separate module.
Websockets moduleacts as a proxy to caldav.

Other

Delay getting a change table entry when realiasing. Was intefering with a test in update.
Getting deadlocks when deleting tombstoned events. Change the colpath so they disapppear but need a purge process to finally remove them.
Tasks collections were not getting created with correct type - nor were they returning a supported component type.
Some fixes to the selfreg feature and additions to the cli to drive it.

1.2.11. Release 3.11.2:

Indexing

Add a reindex operation which reindexes all the data in place. Used when ES schema changes.
Add an indexstats operation to get counts for a named index
Add a setProdAlias operation. Rebuild index no longer automatically makes new index prod. This also allows us to back off the index.
Extra operations added to cli to reindex and change indexes
Fix update of UpdateInfo in ES index. Was doing a string concat rather than an increment.
Index individual location fields so they can be searched
Add a fetch single event method to the indexer
Synch around event cache accesses

Notifications

Add a preference to allow suppression of notifications for a user. This shoudl be applied to public-user to avoid a lot of overhead
Change logging is now modified. Messages are now logged to audit.org.bedework.chgnote. Requires a change to standalone.xml or the equivalent

Sync and orgSync:

Add orgSync connector to sync engine
Fully index location sub-fields - add a set of keys for mapping locations
New indexer methods to enable searching for particular location keys
Allow specification of a mapping key in subscription and in x-property
Updates x-calendar xsd for mapping key as param
Changes to admin client to allow specification of orgSync
Upgrade to httpClient to handle orgSync certs
Add further parameters to OrgSync subscription -updated admin client to support
Unsubscribe before deleting content to avoid race.
Get persisted event on fetch for update
Allow for pw without id in subscription - it’s the key in OrgSync
Implement setting category on add and update from containing collection.
Update was setting datestamps before checking for no changes - was propagated to db entity preventing further updates.
Do a better job of setting content-type and encoding for SOAP interactions.
Add array of keys to location entity for use by synch process.
Fix handling of locations in Synch engine. Add the locKey parameter to the location. It gets propagated to the x-prop for use later.
Refresh rate wasn’t getting through. Fixed

Public events admin

Try to mitigate errors caused when a validation error occurs on publish. Indexed and db version did not match.
Added missing retry action in event submit.
Fixed race condition when selecting a group in admin client
Fix the eventsPending page. POST was losing the filter
Calsuite specific approvers
Avoid ConcurrentModificationException in admin client
Changes for eventreg
- Add some commands to cli
- Use wildfly modules
- More HttpUtil methods for use in eventreg and sync
- Fix web.xml and post-deploy for wildfly
Use of deleted flag
- Index the flag
- Changes to allow DeleteEventAction to just set the flag
- Searching can filter on deleted flag
- Add mark deleted button to form
Add tool command to set authuser roles
Add tool command to add/remove approver for calsuite

Clients

Fix errors caused by entry into showEventMore with a new session
Switch public client to use href in urls instead of calPath + guid + recurrenceId
Last date in header was the same as the first date

Other

Removed the principal path elements from the basic config. Changing them is always a bad idea so they may as well be fixed.
Use wildfly modules where possible - ensure we get consistent SOAP behavior
Further changes for httpclient. Fix to timezones
Logging changes to try to reduce output
Try to spot ConnectionResetByPeer errors and leave quietly
Try to make less noise when a hung session is shut down
Avoid tzsvr startup errors - and db should be static
Allow setting of session timeout in deploy properties
Drop deprecated jboss config
Allow setting of soap address in post deploy
Try to fix some issues with JMX which surfaced when testing eventreg
Add an Events method to calculate instances for recurring event
Fix carddav logging
Add flag to ifInfo to indicate a dontKill server process. Stops autokill killing off some of the long running system jobs.
Fixes to get carddav working again. Most of them backported to 3.11.1
Fixes to get vpoll working again. Broke as a result of ical4j upgrade.
Add event dumping to the new (incomplete) dump format.
Try another approach to stop exceptions when a new user turns up

1.2.12. Release 3.11.1:

Change the schema and filter to allow searches on x-properties.
Backported carddav changes from 3.11.2

1.3. System Overview

Bedework System Architecture

Bedework has a central server architecture and is modular and extensible. It consists of the following components:

Bedework core calendar engine
Public events web client, called a “Calendar Suite”, for display of public events
Public events cached feeds and widget builder, supporting ical, json, and XML and for producing embeddable JavaScript widgets for use on other websites.
Public events administration web client for entering public events, moderating pending events from the submissions client, and configuring calendar suites
Public events submission web client for authenticated members of your community to suggest public events – these become pending events in the admin client
Personal and group calendaring web client with a subscription model to Bedework public calendars, user calendars, and external calendar feeds
CalDAV server for integration with CalDAV capable desktop (and web) clients such as Apple’s iCal or Mozilla Lightning
CardDAV server that supports contacts for scheduling in the personal client.
A JavaScript-only CardDAV address book web client is available for use with the CardDAV server. The address book comes with the Bedework personal web client, and is suitable for use with other web applications (e.g. webmail).
TimeZone server for support of timezone information.
Dump/Restore command-line utilities for database backup, initialization, and upgrades.

1.3.1. Calendar Architecture

The Bedework system is divided into two main spaces: the public events space, and the personal and group calendaring space which are kept separate by design. Public events are stored below a public calendar root folder and personal calendars are below a user calendar root folder.

Personal calendar users (and other clients) can subscribe to public events, but users may only add public events using the Administrative and Community Submissions web clients. For more information about Bedework’s public and personal event calendaring models, see Public Events Calendaring and Personal & Group Calendaring.

1.4. Bedework History and Background

Bedework was established in March 2005 in succession to UW Calendar. In December 2006 Bedework received the Andrew W. Mellon Foundation’s Technology Collaboration (MATC) Award. Since then the project has prospered, and in early 2009, Bedework became an incubator project of Jasig (http://www.jasig.org/) now a part of the Apereo Foundation (http://www.apereo.org).

Bedework is in use by institutions large and small, educational, governmental, commercial, and non-profit.

Bedework is named after the Venerable Bede, a highly influential monk and scholar from the area of Northumbria in Britain who in 725AD wrote the treatise, "On the Reckoning of Time". Bede is pronounced like “bead”, Bedework is pronounced “bead work”.

1.5. Calendaring Standards & Interoperability

The Bedework implementation team participates in the standards process as a member of CalConnect, the Calendaring and Scheduling Consortium, which is "focused on the interoperable exchange of calendaring and scheduling information between dissimilar programs, platforms, and technologies."

Interoperability with other calendar systems and clients by way of standards compliance is an important design goal of the Bedework system.

Bedework is designed to conform to existing calendar standards. For more information about calendaring and calendaring standards, please visit the CalConnect Devguide.

1.6. Underlying technologies

The following lists some of the core technologies used by the Bedework platform:

Apache Struts MVC
CalDAV
Cascading Style Sheets (CSS)
iCAL: RFC 5545
iCal4j
Java Servlet API
Java Server Pages (JSP)
JavaScript (including jcal, jQuery, jQueryUI, Bootstrap, and others)
Portlet API: JSR-168
XHTML
XML
XPath
XSLT

2. Public Administrator Features

2.1. Public Events Registration

Bedework supports a public events registration system that allows authenticated users to register for events. Users may view and modify their registrations, such as unregistering or changing the number of tickets they’ve requested. When registration is full, users may choose to be placed on a waiting list. Users on waiting lists will automatically be moved up in the queue if space becomes available.

With the form elements as shown below, administrators can specify how many users may register, how many tickets each registrant may request, and set the opening and closing dates of registration. Administrators can view and modify a registration list and download CSV files of their registrations on-demand.

2.1.1. Displaying the current status

Clicking on the "View registrations" button will take you to a screen showing the current registrations for the event. This screen also allows the administrator to hold some tickets and to update or remove registrations.

2.1.2. Custom Fields

Administrators may add custom field elements for use during registration. These custom fields are displayed to the user when they register for the event. These fields can be used to obtain extra information from the user as they register, for example dietary restrictions.

Currently the results are only visible in the downloaded registrations.

2.1.3. Data elements

Data about the event is maintained in x-properties attached to the event and provides the following information:

Booking window start and end
Number of tickets
Max number of tickets per person

2.2. Subscribing to a feed for public calendars.

You probably want the incoming events to all be flagged with a specific category or categories. This can be useful for filtering.It makes it easier to include the calendar collections imported by the sync engine. Before carrying out the following steps ensure these categories are created.

For public events there are a few more options available when subscribing.

Process Locations and Contacts: This causes locations and contacts to be moved into x-properties "X-BEDEWORK-LOCATION" and "X-BEDEWORK-CONTACT". The receiving end (bedework) may carry out further actions to validate the location or contact and as a result may set a preexisting location or contact in the event. The x-property is always available for display but this process allows the system to validate the location/contact.

Process categories: This does the same for categories.

2.2.1. Note:

If you don’t select those options then categories and locations will be created in bedework. This is probably not what is wanted as these are uncurated.

By setting the Process…. flag you ensure that such locations and categories don’t end up in the database.

Suppress deletion of events? This means that if events disappear from the feed they will stay in the database. This effectively turns the feed into a change feed adn can significantly reduce the size of the data. It does mean that events that MUST be deleted will require help from an administrator with sufficient privileges.

2.2.2. Creating a public subscription

As a super user

Switch to the System tab and select "Manage calendars and folders".
Open up "public" and click the "+" on the cals folder.
Set the name - e.g "Athletics"
Check off categories for filtering
- Click on "show/hide categories used for filtering"
- Scroll down and select a previously created category or categories
Check off any categories you want applied on input -
- Click on "show/hide categories for auto-tagging on input"
- Scroll down and select a previously created category or categories
Mark as a subscription
Set the URL in the URl field
Set an id/password if necessary
Select the "Process Locations and Contacts" and "Process Categories" checkboxes if desired (probably so)
Set the location key field name for mapping locations
Set the refresh rate in minutes
Save

2.2.3. Mapping Locations

Locations created and stored within bedework are broken out into a number of fields. Out of these the following are used to create a combined address value which is used for export and import mapping:

Street address
Room
City
State
zip/postcode

These values are separated by a comma and a space. Missing values are skipped.

The update process matches the value of the supplied LOCATION property against that combined value.

If there is an EXACT match then the bedework location will be attached to the syncronized event. Otherwise the location will be left in the x-property. Feeds and the front end display will normally display the x-location as the location for the event.

2.2.4. Mapping categories

An equivalent process takes place with categories though the mapping is much simpler. Categories only have a single value. An exact match in the imported event will cause the bedework category to be applied.

The use of bedework categories is important for much of the front-end filtering of events as this is driven primarily by categories.

As an example if we have the alias structure
performances/comedy
and comedy is tagged with the category comedy and performances with the category performances then the imported event needs both categories.

2.2.5. Examples

2.3. Public events authorised users

These are users with rights to create events, perhaps publish them and possibly have access to calendar suite setup.

2.3.1. Creating a user

Go to the "Users" tab and click on "Manage Admin Roles".

If the user does not appear in the list then type the account into the box labeled "Edit admin roles by userid" and hit enter.

All users should have the "Public Events" flag set.

Users who may create but not publish should have the "Content Admin" flag set.

Users who may create and publish will also have the "Approver" flag set.

2.3.2. Updating a user

Go to the same location, "Users" → "Manage Admin Roles", locate the user in the list and click on the "edit" link.

Flags may be set or unset from there.

2.3.3. Updating group membership.

Until the user is added to a group or groups they cannot create events. Each calendar suite will have one or more groups associated with it. Typically there is an admin group associated directly with the suite and a submission group which is a member of the admin group.

Approvers are typically added to the admin group and event creators get added to the submission group.

To add a user or group click on "Users" then "Manage Admin Groups".

Find the group to update and click on the "membership" link.

To add a user enter their account in the "Add member" box, ensure "User" is selected then press the "Add" button.

To add a group ensure "Group" is selected.

To remove a group member, click on the trash icon next to the account.

2.3.4. A problem to be resolved later:

Note that the rights of the users are attached to their auth user entry. So a user is always an approver whatever groups they are in.

There is no provision for a user being an approver in one group and an event creator in another. At some point we may move the rights to the associated groups so that approval rights will come about because of group membership.

3. Deployers

3.1. Installing the quickstart (3.12.x onwards)

The current quickstart is installed by executing a script which will create the quickstart directory and then download, clone and build. In the event of a failure part way through, the script may be restarted with the restart parameter.

Note	This requires git 2.x or greater. The clones use a tag rather than branch and this does not work for older gits.

The latest script may be downloaded from github. Alternatively clone the bedework repo and use the script at bedework/build/quickstart/linux/installQS.sh

Specific versions of the script are at:

3.1.1. Which version

The script will ask you if you want the development or latest version.

3.1.2. Apacheds

The script will install apacheds. This will install a directory with some initial ids in place for testing. Ultimately you’ll want to use your own directory service.

3.1.3. ElasticSearch

You need a running elasticsearch - release 7.2. The quickstart install will optionally install a docker image and customize it for the quickstart.

This requires you to have docker and docker-compose installed first.

The elasticsearch instructions related to installing a docker image can be found at https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html

After the install is complete there will be 2 scripts startES.sh and stopES.sh which will start and stop the docker image.

If you want to install your own copy and configure it there is an elasticsearch.yml configuration file in bedework/conf/bedework/elasticsearch. Use this to replace the config in the downloaded ES.

3.1.4. Maven

This is a maven project and as usual you need to set up your maven profile in ~/.m2/settings.xml. The script will display a possible settings.xml file with the paths filled in.

If you want to merge in the profile to an existing settings.xml ensure you also merge in the pluginGroups section.

The profile does not need to be active by default if you have other profiles. The build process will specify the bedework-qs profile.

Below is the contents of an example settings.xml file. This file must be set up before allowing the script to continue on to the builds otherwise they will fail during deployment.

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                         http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <pluginGroups>
    <pluginGroup>org.bedework</pluginGroup>
  </pluginGroups>

  <profiles>
    <profile>
      <id>bedework-3</id>
      <activation>
        <activeByDefault>false</activeByDefault>
      </activation>
      <properties>
        <org.bedework.deployment.basedir>$qs</org.bedework.deployment.basedir>
        <org.bedework.deployment.properties>$qs/bedework/config/wildfly.deploy.properties</org.bedework.deployment.properties>
      </properties>
    </profile>
  </profiles>
</settings>

3.1.5. Default Maven Profiles

Note there appears to be a bug in the use of activeByDefault. Explicitly specifying a profile with the maven -P parameter is supposed to deactivate a profile marked as activeByDefault. This is not (always?) happening.

If you only have profile marking by default should be fine. To ensure only one profile (or the expected profiles) are active cd into the project and try

mvn -P bedework-3 help:active-profiles

To alleviate some of the issues of having multiple profiles for bedework builds the bw script now sources a .bw file in the home directory which can set some defaults. At the moment the only default is the profile. An example .bw file is:

#
# Defaults for bw script
#
echo "Setting defaults from .bw"
bw_mvnProfile="-P bedework_dev"

Note the setting needs to include the -P.

3.1.6. Security

During the install an id and password will be set up so that the install process can reindex the data. These will allow use of the cli and the hawtio console.

3.1.7. Building

In many cases it is possible to simply cd in to the appropriate directory and do a mvn install with the bedework-3 profile. However there is a bw script which - while taking longer - does build all projects a module depends upon. This avoids the need to work out the dependency orderings of the independent projects. Thus

./bw deploy

will build a lot of projects eventually building the client project which deploys an ear file.

3.1.8. Deploying

As part of the bedework project there is a maven plugin which uses a properties file to handle post-build deployment issues. Essentially the ear or war as built acts as a template for the deployer.

The deployment process may involve inserting filters for CAS, adding property values to web.xml files, cloning entire wars for calendar suites etc.

The file bedework/config/wildfly.deploy.properties is the quickstart version of that file.

When developing your own service the first thing to do is create a repository with your files and copy the above file into that repository. Then set the org.bedework.deployment.properties value in your maven settings.xml to point to that file.

DO NOT change the org.bedework.deployment.basedir property - unless you move the quickstart. This property is used to locate the wildfly instance.

3.2. Configuring wildfly

3.2.1. Adding an admin account

cd wildfly
./bin/add-user.sh

   What type of user do you wish to add?
    a) Management User (mgmt-users.properties)
    b) Application User (application-users.properties)
   (a): b

   Enter the details of the new user to add.
   Using realm 'ApplicationRealm' as discovered from the existing property files.
   Username : hawtio-admin
   Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
    - The password should not be one of the following restricted values {root, admin, administrator}
    - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
    - The password should be different from the username
   Password :
   Re-enter Password :
   What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[  ]: admin
   About to add user 'hawtio-admin' for realm 'ApplicationRealm'
   Is this correct yes/no? yes
   Added user 'hawtio-admin' to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/standalone/configuration/application-users.properties'
   Added user 'hawtio-admin' to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/domain/configuration/application-users.properties'
   Added user 'hawtio-admin' with groups admin to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/standalone/configuration/application-roles.properties'
   Added user 'hawtio-admin' with groups admin to file '/Users/xxx/dev/eap/wildfly-8.1.0.Final/domain/configuration/application-roles.properties'
   Is this new user going to be used for one AS process to connect to another AS process?
   e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
   yes/no? no

Setting up databases

The quickstart is configured to use h2 for demonstration only. For production you will need to switch to something like postgresql or mysql.

postgresql

We’ll describe the process for the main calendar engine. The others are very similar.

All bedework and wildfly configuration files are in standalone/configuration/ - we’ll just refer to the relative path.

Name: caldb (you can change that if you wish)
Configuration: bedework/bwcore/dbconfig.xml
datasource: CalendarDS

Configure postgresql

You’ll probably need to configure postgres to allow your chosen role access to the server and databases.

Depending on how you’re running the system you may need to modify postgresql.conf and pg_haba.conf - both located by default in the daat directory.

If you’re running postgres on a separate system you may need to change the listen_addresses value and port:

listen_addresses = 'localhost'     # what IP address(es) to listen on;
                                   # comma-separated list of addresses;
                                   # defaults to 'localhost'; use '*' for all
                                   # (change requires restart)
port = 5432                        # (change requires restart)

Change "localhost" to "*" or a list of addresses.

5432 is the default port.

To allow your account access you will need to add a line or lines to pg_hba.conf near the end something like:

host    all             bedework        10.0.0.1/32        md5

This can be made more restrictive by naming the db.

Create a database with a known id/password. Ensure it is accessible from the host you are running bedework on.

The psql commands are something like:

create role bedework with login password 'xxxxxxxxx';
create database caldb owner bedework;

Set the hibernate dialect in the config file:

    <hibernateProperty>hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect</hibernateProperty>

In standalone.xml replace the datasource definition with something like:

    <datasource jta="true" jndi-name="java:/CalendarDS" pool-name="CalendarDS" enabled="true" use-ccm="false">
       <connection-url>jdbc:postgresql://localhost:5432/caldb</connection-url>
       <driver>postgresql</driver>
       <pool>
         <min-pool-size>1</min-pool-size>
         <max-pool-size>50</max-pool-size>
         <prefill>true</prefill>
      </pool>
       <security>
         <user-name>xxxxx</user-name>
         <password>xxxxx</password>
       </security>
       <timeout>
        <idle-timeout-minutes>15</idle-timeout-minutes>
       </timeout>
        <validation>
          <validate-on-match>true</validate-on-match>
          <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>

          <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
       </validation>
       <statement>
         <share-prepared-statements>false</share-prepared-statements>
       </statement>
     </datasource>

Ensure you also have the driver loaded - for example the drivers section which usually follows the datasources shoudllook somethign like:

You need to install the postgres driver - you’re either missing the driver declaration - something like:

<drivers>
    ...
    <driver name="postgresql" module="org.postgresql"/>
    ...
</drivers>

Ensure the jdbc driver is installed in the modules directory - something like:

wildfly/modules/org/postgresql/main/module.xml
wildfly/modules/org/postgresql/main/postgresql-8.4-701.jdbc4.jar

Module.xml for this example contains

<?xml version='1.0' encoding='UTF-8'?>

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
    <resources>
        <resource-root path="postgresql-8.4-701.jdbc4.jar"/>
    </resources>

    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

Modify it appropriately for different versions.

Start wildfly and allow it to fully deploy. There will be many errors relating to the calendar database.

Delete the file wildfly/standalone/data/bedework/dumprestore/schema.sql

Use the cli to install the schema.

To run the cli you need the id and password you created when configuring wildfly. This id and password can also be used to access the hawtio console.

cd bw-cli/target/client/bin
./client -id admin-id -pw admin-pw
calschema export

This should install the schema. It will also create a file which can be manually installed if need be - use the psql client application

psql caldb < wildfly/standalone/data/bedework/dumprestore/schema.sql

Next you need to add some basic data. For this you need the full path to the initial data in wildfly/standalone/data/bedework/dumprestore/initbedework.xml

In the cli enter the command

restoreCal "/full/path/to/initbedework.xml"

The quotes are required. Some activity should ensue.

Reindex the data - again use the cli

rebuildidx

wait for it to terminate - then enter

listidx

The alias bwuser should be pointing at the index before the last one just created.

In the cli

makeidxprod index-name

replacing index-name with that last name - no quotes.

MySQL

TBD

Set the hibernate dialect in the config file:

    <hibernateProperty>hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect</hibernateProperty>

3.3. Elasticsearch

Bedework uses ElasticSearch as the indexer engine. As objects are created destroyed and updated they are indexed through calls to the indexer. The indexer can run as an embedded engine - as it arrives in the quickstart - or as an external service - which will be required for clustering.

Currently elasticSearch is completely unsecured. For testing and debugging it is possible to enable the http interface but this may expose your index. DO NOT run in production with the ES http interface open. In embedded mode the only access should be through the api.

Later versions of ES do appear to offer the ability to secure ES. This may be an option when we upgrade.

In non-embedded mode you can run ES on the same server or preferably a different server. ES - depending on the amount of data and types of search - can use a lot of memory for caching of filters. See the ES site for full instructions on running a non-embedded version.

In general this is an easy process - ES offers various installation formats of all their versions including the very old 15.2 we are running currently.

Both embedded and non-embedded require a small number of changes to the configuration. These are already in place for the embedded version and are available in the quickstart in

bedework/config/bedework/elasticsearch/config/elasticsearch.yml

Note that the mappings and settings do not need to be installed. They are used when creating a new index.

The changes made are

action.auto_create_index: false

Prevent ES from creating indexes implicitly. This can cause issues when reindexing.

Uncomment the following

node.max_local_storage_nodes: 1 [[configure-events-registration] === Enabling and Disabling Public Events Registration ==== Enabling Public Events Registration

The public events registration system is enabled by default if you have installed Bedework with the data available in the quickstart.

3.3.1. Disabling Public Events Registration

If you wish to disable the public events registration system remove the "Eventreg admin token" from the System Preferences in the jmx console:

Log into the Bedework jmx console, e.g. http://localhost:8080/hawtio
- Click "org.bedework.bwengine" in the left menu, then "service=System" in the right menu
- Remove the value in the EventRegAdminToken field
- Click "Apply Changes"
- Invoke "saveConfig" to save your changes.

3.3.2. Enabling Public Events Registration (possibly after upgrade from a previous release)

First ensure that the CalWs interface is available. This is the SOAP service that the event registration service uses o communicate with bedework. In system.xml make sure the <calSoapWsURI> element is present and has the same value as the soap:address element in pubcalws-soap/wssvc.wsdl (this requires better explanation - it’s a file deployed in the bw-xml ear)

If you have upgraded from an older release, you may not have the data required for event registration in your system yet. Follow these steps to turn on the event registration system: (Please note: the process outlined below is only set up for the default quickstart and postgresql configs at the moment.)

Start up jboss and apacheDS
Log into the JMX-Console shipped with Bedework’s JBoss, e.g. http://localhost:8080/hawtio
- Click "org.bedework.eventreg" in the left menu, then "service=Eventreg" in the right menu
  - If no database exists:
  - Set “create” and “export” attributes to "True"
  - Click "Apply changes" button (at the bottom of the list of attribute values)
  - Find the "schema" operation in the lower list, and click the “Invoke” button to export schema and create database
  - You should see a successful result; click "Back to MBean" button to return to "service=Eventreg"
  - Point at needed systems:
  - Set the WsdlUri attribute value to: http://localhost:8080/wsdls/pubcalws-soap/wssvc.wsdl
  - Set the TzsUri attribute value to: http://localhost:8080/tzsvr
  - Click "Apply changes" button
  - Admin token:
  - If no admin token exists, click “generateAdminToken”
  - You should see a successful result; click "Back to MBean" button to return to "service=Eventreg"
  - You should see a string such as "c0e93685-93cd-4bee-bed2-9996b89be28c" in the EventRegAdminToken attribute value.
  - Copy the EventRegAdminToken value (for use in the next step)
- Click "org.bedework.bwengine" in the left menu, then "service=System" in the right menu
  - Paste the value into the EventRegAdminToken field
  - Click "Apply Changes" button
  - Invoke the "saveConfig" operation to save your changes.
Test:
- Add a new public event. You should be able to select the checkbox "Users may register for this event", and make the event registerable.
- Visit the event in public client — you should be able to register for it.

3.3.3. Notifications from EventReg

The event registration service will send notifications to the calendar engine when changes take place that might require notifying users. The event registration service calls the calendar engine notification web service (not to be confused with the notification engine). This web service allows the core engine to add notifications to the accounts of subscribed users. It is the job of the notification engine to forward those via email or some other service.

To configure notifications from eventreg you need to set the BwId, BwToken and BwUri properties in "service=Eventreg"and the NotifierId and NotifierToken values in "org.bedework.bwengine" → "notifications"

[[deploying-sync-engine] === Deploying the sync engine The synch engine handles the synchronization of external subscriptions with a bedework calendar - for example a Google web calendar or an ical feed from a department.

Currently such a synchronization must be carried out to a single calendar collection which only contains data from the external resource. Also only one way synchronization is supported - inbound to bedework.

These subscriptions are available to personal calendar users and to public events administrators. For personal calendar users the options are limited as it is intended only to mirror the external resource.

3.4. Initializing the database

If running with mysql the built in hibernate schema export doesn’t work - mysql jdbc does not support it.

The schema is simple however - it can be generated via the JMX mbeans or use the examples below - to install it manually, create a database - ensure UTF-8 is enabled

CREATE DATABASE `synchdb` DEFAULT CHARACTER SET utf8;
grant all on synchDb.* to '<id>'@'%' identified by '<pw>';

and then create the single table:

CREATE TABLE `bwsynch_subs` (
  `bwsyn_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `bwsyn_seq` int(11) NOT NULL,
  `bwsyn_subid` varchar(250) NOT NULL,
  `bwsyn_owner` varchar(500) NOT NULL,
  `bwsyn_lrefresh` varchar(20) DEFAULT NULL,
  `bwsyn_errorct` int(11) DEFAULT NULL,
  `bwsyn_missing` char(1) NOT NULL,
  `bwsyn_connectorid_a` varchar(100) DEFAULT NULL,
  `bwsyn_conn_props_a` varchar(3000) DEFAULT NULL,
  `bwsyn_connectorid_b` varchar(100) DEFAULT NULL,
  `bwsyn_conn_props_b` varchar(3000) DEFAULT NULL,
  `bwsyn_props` varchar(3000) DEFAULT NULL,
  `bwsyn_dir` varchar(25) NOT NULL,
  `bwsyn_mstr` varchar(25) NOT NULL,
  PRIMARY KEY (`bwsyn_id`),
  UNIQUE KEY `UK_qptomm2syatpqumsl1udwk7be` (`bwsyn_subid`),
  KEY `bwsynidx_subid` (`bwsyn_subid`),
  KEY `bwsynidx_subowner` (`bwsyn_owner`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

3.4.1. (Re)build bw-xml

The synch engine uses an extension of CalWS to communicate with bedework. It requires that the wsdl file contain the location of bedework. This is configured into the deploy.properties file - only one change for the synch engine should be necessary. Set the location of (one of) your application servers in the following.

# ------------------------------------------------------------------------
#       wsdls; ear bw-xml
# These go together - first name the wsdl directories and files...
org.bedework.app.bw-xml.bwwsdls.wsdl.synch=wssvc.wsdl

# then provide the global properties
org.bedework.global.synch.service.location=http://localhost:8080/synchws/

If you are running everything on one server then the quickstart setting above will do. Note that at the moment the synch engine can only work against a single bedework server. It can accept requests from any member of the cluster however. Keys

Generate a set of keys using the cli.

cd bwcli/dist/temp/shellscr/bwcli/ (or wherever your binary is)
./bwcli.sh
/usr/lib/jvm/java-8-oracle/bin/java -cp .:./classes:./resources:lib/bw-access-3.11.0.jar:lib/bw-annotations-3.11.0.jar:lib/bw-calfacade-3.11.0.jar:lib/bwcli-3.11.0.jar:lib/bw-ical4j-vcard-1.0.5.jar:lib/commons-collections4-4.0.jar:lib/commons-lang-2.3.jar:lib/commons-lang3-3.3.2.jar:lib/commons-logging.jar:lib/httpclient-osgi-4.3.3.jar:lib/ical4j-2.0.6.jar:lib/jackson-annotations-2.1.1.jar:lib/jackson-core-2.1.1.jar:lib/jackson-databind-2.1.1.jar:lib/jolokia-client-java-1.3.1.jar:lib/json-simple-1.1.1.jar:lib/log4j-1.2.8.jar:lib/rpiutil-3.11.0.jar org.bedework.bwcli.BwCli
JMX id:<your id>
Password:<your password>
cmd:genkeys gen
test with---->A variable of array type holds a reference to an object.
encrypts to-->BaUPfgTjzZxxbbW+lJACxmdo56tldkgfnr7LERkRTVyLQJh0kVt+GJZgJA1k9Wm+ojvpJCYFl34ybTy0vX2PM8Tu0+UsMKeV3HDi24NW6cH+C+QQ6XATLtskiBPhUQufpHBIKCke08PNh24xCoIk9+hllLgQQNCgVB1JQnQA0ak=
decrypts to-->A variable of array type holds a reference to an object.

Validity check succeeded

If you are using multiple servers copy the resulting key file from <quickstart>/wildfly/standalone/data/bedework/ on to each server. Ensure calendar server(s) can locate the synch engine.

The bwengine/synch settings are configured to use a jvm system property to locate the synch engine. In file <quickstart>/wildfly/standalone/configuration/bedework/bwengine/synch.xml you should see:

<?xml version="1.0" encoding="UTF-8" ?>

<synch xmlns="http://bedework.org/ns/" type="org.bedework.calsvc.jmx.SynchConfigImpl">
  <connectorId>localBedework</connectorId>
  <managerUri>http://localhost:8080/synch/manager</managerUri>
  <wsdlUri>http://localhost:8080/wsdls/synch/wssvc.wsdl</wsdlUri>
</synch>

If you are using multiple servers change the host in <managerUri> to refer to your sync server.

3.4.2. Validating locations.

When an event arrives at the receiving end with an "X-BEDEWORK-LOCATION" property if the String value of the x-property is … === Locations in bedework

These are stored internally as location entities. They are created withthe admin client for public events or as a result of specifying or receiving locations for user clients.

3.4.3. Searching for public locations

There is a web service endpoint which can be used to search for public locations. It takes a filter expression as a parameter and will return <a limited?> number

A search takes the form:

<scheme-host-port>/locations/all?[params]

The params are * fexpr=expression * ?

The expression is a valid filter expression. Of particular interest are the following

loc_all=a-string
geo?
?

For example

http://localhost:8080/cal/location/all.gdo?fexpr=loc_all=%27some%27

4. Development

4.1. Todo list

This is a (moderately) sorted list of features/changes etc for bedework. Could be a set of tickets but this is easier to read.

4.1.1. Imminent changes

Intend to get round to these ones Any Time Now(tm) * Filter x-properties in public clients/feeds - list of x-props to retain.

4.1.2. Future changes

These are longer term. Will pick away at these as time allows.

Api changes

Change the api to use response objects throughout. No exceptions. Allows for a better networked api.

Notifications

Need to be indexed in ES so that finding a notification for an entity is efficient (need to merge multiple notifications for same entity) Change notifications for public events is probably not working correctly. We should be using the creator - or the owner of the alias - all public events have the same owner (public-user) and change notifications seem to be ending up in that bucket.

Limit interactions with db for updates.

For this we would do all interactions with ES and connect to and update db only as needed. Use sequence numbers to ensure db and index correctness. Benefits are shorter db interactions - only at point we update. Less complexity in web clients - no need to have conversations stretching across multiple requests. This can build on the work of the previous item. The web client code is already structured ro assume that it will do an explicit update of entities which should facilitate the change.

Move business logic out of webapps into core

Move as much as possible out of the current webapps module into the core APi implementation - this potentially allows a more RESTful style of client - possibly using the new jmap style interface being developed.

Locations

Allow for use of external location sources such as geonames. Will allow good locations on external events.

Searching improvements

Search for events near a geo-location (requires locations to have geo)

Caching

Implement caching of feeder data as a built in feature of the quickstart.

Deployment of ears

Finish off the deployment process - it’s THAT close (is there an emoticon for 2 fingers very close together?) to allowing deployers to just replace the ears from prebuilt ears on the site. No builds required - server can detect an update is available.

Deployment of wildfly modules

If all - or many - required dependencies are deployed as wildfly modules it should reduce the size of the deployment and allow for even quicker startup.

Networked client api

Subset of svci but can be used for web client interactions.

Groups

Directory interface to directly interact with grouper for user and admin groups. Allow consumer only approach for external management of groups. Use extra ldap attributes to allow admin groups to be maintained in ldap.

Index logs in ES

Use kibana to get metrics etc

Timezones

Update UI to provide a search - possibly based on map. Use tzdist geo feature (being developed)

General work needed

Upgrade ES to latest - changes the query structure
Upgrade all libraries to latest
Preprocess the xsl to build the deployable language specific versions.

4.2. Running the caldav tester

The tester started as an Apple developed project to test CalDAV servers. It has since been taken over by CalConnect adn is in the process of being modified to make the tests more universally applicable.

4.2.1. Setup

To run some basic tests there is a script bw-caldavTest/src/main/resources/calconnect-tester/testbw/bw-QuickLook-CalDAV.sh

This script sets up the tester which needs to be cloned from the repository.

Running the tester requires that a number of users be provisioned in a particular state.

The quickstart data comes with users user01-user04. Each is setup with

cn: 01,test
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
sn: user
givenname: 01
mail: user01@mysite.org
uid: user01
password: bedework

(Replace 01 with 02-04 for the rest)

5. Older Bedework Versions (3.10 and Prior)

3.10.4

December 14, 2016

Significant web client performance improvements
Fixes to sharing
Enhancements to the notification system

3.10.3

Core engine
- Flag all entities as indexed
- Fix hibernate query which pulled in too many objects
- Fix bug in ES query which missed a number of recurrences
- Fixes to synch report
- Fixes to sharing
- Work on notifications
- Allow disable of ldap group check
- Add code to stop autokill killing the indexer
- Better cleanup of http connections
- Fix up timestamps in ical
- Dumprestore sets status of process
Caldav
- Better handling of error conditions
- Better error responses
- Fixes to content type
- Eventreg
- Fixes for eventreg id
- Use activemq to queue actions so they don’t get lost on restart
Webapps
- Some fixes to the grid view
- Remove a synchronized to reduce a bottleneck
- Try refactor and recode calendar collection cloning for navigation
- Fix copy of event
- More cleanup of http connections
Util
- Allow deployer to work with war files
- Add jms classes extracted from sysevents module
- Add jolokia module to allow a client to interact with jmx
Webdav
- Minor propstat fix
- Better error responses

Bedework 3.10.2

Performance Improvements
- numerous updates to correct for bottlenecks and other performance issues allowing for significant load and large-scale deployments
External Subscriptions
- significant improvements to external subscription handling
- better handling of contacts and categories for public calendaring
Workflow (public calendaring)
- new author and approver roles allow for moderated publishing of events by administrative groups
Cross-Suite Suggestions (public calendaring)
- new suggestion mechanism allows different calendar suites to suggest and accept (or reject) events across teams
Event Registration (public calendaring)
- significant improvements to event registration features
- addition of custom fields to any registration form and a form builder for constructing and managing custom forms (extra text inputs, checkboxes, radio buttons, and select boxes)
- email notifications (see Notifications)
Notifications (public calendaring)
- In public calendaring, administrative users now receive notifications of actionable items (workflow approval requests, suggestions from other groups, and responses to each)
- In event registration, the notification engine is used to communicate with registrants concerning registration, waitlisting, and event cancellation
Self Registration
- Allows users to register with the calendaring system so that they may register for public events
Web Client Improvements
- Improvements to the public administration client
  - Locations can be broken into locations and sub-locations (i.e. buildings and rooms)
  - Rooms can be added on-the-fly during event creation
  - Improved location and contact look-up during event creation
  - Numerous other stylistic and usability enhancements in the administrative client
- Improvements to the public web client
  - improvements to accessibility compliance
Bug fixes

3.10

A largely-revamped public client, which features:
- Responsive design - the public client will display reasonably on almost any screen size.
- More powerful and flexible left-hand navigation - in just a few clicks, site visitors can ask for the "Arts events and Films taking place on West Campus"
- Event filtering by string. – ex., “Arts events and Films on West Campus that include 'Sherlock'".
- An endless stream of events - All events that match the criteria are presented, starting with today’s events (or any other date specified), and advancing into the future. An initial group of events are displayed on the page, and as the visitor scrolls towards the bottom of the page, the next group is presented.
- Improved performance with fewer page reloads - most operations, such as adding or removing a filter, are done "in-page" (using Ajax calls).
Enhancements to indexing
- Bedework 3.10 has a new search engine – ElasticSearch. In the Bedework context, ElasticSearch, provides better remote management of indexes, better scalability options, and much simpler configuration than Solr. ElasticSearch is used by, among others, Wikimedia, Foursquare Etsy, and GitHub.
- Improved performance and scalability by directing most queries to an ElasticSearch index rather than directly to the database engine
More real-time site configuration
- All configuration settings are now set through the JMX console, eliminating the need for rebuilds to reconfigure
An improved Quickstart
- A smaller (~40%) Quickstart - no-longer-used code (such as webcache) and unused JBoss components have been removed
- Better Quickstart documentation

3.8.0.13

April 17, 2012
* Administrative client: Support for image uploads and auto-generation of thumbnails during event creation and editing "Manage events" page now uses date range and date navigation to list events The event description field now tracks the number of characters used while the user types. Pending event topical areas are auto-selected (when possible) based on the selections made in the submissions client Pending event "preferred" and "all" listings are correctly selected when first editing a pending event "Preferred" and "all" listings now sorted Auto-focus first available field code updated to be more generally useful (based on work done by Eric Wittman Bug fix: pending event titles are correctly escaped on publish

Public events client:
- Bug fix: correct ids on nodes of the calendar explorer menu (new feature in 3.8)
Submissions client:
- Removed Confirmed/Tentative/Cancelled radio buttons
- Correctly associate selected topical areas between submissions client and admin client (where possible)
Bedework servers / utils:
- Configure Tomcat to fully support UTF-8 URLs
- Bug fixes to dump/restore utilities
- Bug fix: for long standing bug in date/time util.
- Bug fix: missing tz and locale update
- Bug fix: tombstone related bug in methods called by indexer
- Bug fix: correct check for duplicate collection name
- Bug fix: various DST, timezone fixes, support for UTC, etc.
- Bug fix: blob caching fixes

3.8.0.11

February 27, 2012
* Fix issue preventing display of events on a DST boundary. * Fix iSchedule so it works again. * Fix change set so that added/deleted attendees get notified. * Storing of resources/attachments was broken. Required upgrade to hibernate 3.6 * Added some quota support because we can now store resources. * Added some missing datasource files. * Watch out for and fix bad PARTSTAT. * Don’t email freebusy requests. * SOAP namespace change.

3.8

January 30, 2012
* Synchronization Engine, providing more efficient synchronization of external data. read-only .ics subscriptions/feeds into Bedework are supported in this release.

CalWS-SOAP, a SOAP protocol for calendaring being developed by OASIS and CalConnect. Bedework 3.8 uses CalWS-SOAP for communication between the synchronization engine and Bedework.
WebDAV Synch, which is a draft RFC extension to WebDAV/CalDAV (https://tools.ietf.org/html/rfc6578), providing a more efficient method for client synchronization. WebDAV synch is currently supported by iCal - the Apple desktop calendaring client, and also by aCal - an Android CalDAV client (http://andrew.mcmillan.net.nz/projects/aCal).
New UI Feature - a theme setting that produces an explorer view of the calendars for navigation
Quickstart has a smaller footprint
New, simplified theme (using the new calendar explorer menu) providing easier integration with an organization’s web design.
Hypersonic (HSQL) is now packaged with the Quickstart instead of Derby. Derby never met our expectations that it could be deployed as the production DBMS for Bedework, and the advantages of HSQL, including Quickstart support for the Scheduling Assistant, are compelling.
Structural changes to projects.
All references to Bedework documentation are updated in the web clients to point to the Bedework website and latest documentation wiki. Previously, some references were to the older, deprecated bedework.org site, which created some confusion in previous releases.
Various bugfixes

3.7

March 10, 2011
* The Bedework personal client has been simplified, and presents new displays for FreeBusy, and for scheduling and managing meetings.

Bedework 3.7 uses CardDAV for managing contacts, and provides a new, standalone address book web client as well as a significantly improved and enhanced CardDAV V4 server.
Improved internationalization - the web clients are distributed with language strings in Spanish (all clients) and German (public and personal clients). The Spanish translations are the result of a collaboration between the Universidad Pública de Navarra and their Pamplona colleagues at Universidad de Navarra, and the German translation is the contribution of Werner Frerichs of the University of Kiel.
Personal calendaring client UI has been upgraded, with particular attention to Scheduling and Free/Busy
Improved environmentals - Reduced memory footprint in the quickstart; logging overhead has been decreased
Public and private calendar display names can now be changed, providing a means to safely modify the labeling of calendars over time as well as stronger internationalization.
Addressbook enhancements, including a CardDAV V4 server, support for groups, and a stand-alone address book web client appropriate for deployment within multiple applications
An initial version of the CalWS restful web service API is available in the system shipped with the quickstart. See: http://www.calconnect.org/pubdocs/CD1011%20CalWS-Rest%20Restful%20Web%20Services%20Protocol%20for%20Calendaring.pdf
Bug fixes to all servers and clients

3.6

February 3, 2010 * Core Bedework services packaged in JBoss * Spanish translation of public calendaring themes shipped with quickstart * Bug fixes and final enhancements * See Bedework 3.6 Milestone page for information about post-release bug fixes.

3.6 release candidate 1

January 9, 2010
* Public calendaring New default public theme based on Duke/Yale themes Feed URL and Widget Builder for generating rss, json, xml, and ical feeds as well as embeddable javascript widgets A "feeder" application that serves as a common source for public data feeds and widgets A web cache application for storing and serving the feeds and widgets Internationalized and modularized themes New mobile theme for iPhones and other smartphones

System notifications now built on JMS (ApacheMQ) allowing more modular design of the services
- Indexing reworked as outboard process
- Scheduling reworked as outboard process
- Logging of system notifications
Performance improvements
- in CalDAV
- event retrieval (system wide)
Other Enhancements
- improved ical subscriptions, user and public clients
- UI support of deleting collections
- improvements to scheduling in the user client
- subscription coloring in the user client
- general bugfixes
- improvements to documentation

3.5

July 17, 2009
* Bug fixes and final enhancements * See href="http://www.bedework.org/trac/bedework/milestone/Bedework%203.5[Bedework 3.5 Milestone page] for information about post-release bug fixes.

3.5 release candidate 2

June 3, 2009
* Bug fixes and final enhancements * Further support for draft 0.7 of CalDAV scheduling * Improved personal client user interface

3.5 release candidate 1

May 19, 2009
* Performance improvements reduce JVM memory usage decrease database system load

Large-scale restructuring of data and administrative UI to map to new conceptual model of the single calendar pool
public events submissions client enhanced with added workflow in the admin client for pending events, including email notification when an event is published
admin client: cross-tagging of events by administrative groups (currently locate events by searching)
Support for draft 0.7 of CalDAV scheduling
Stronger support for xproperties

3.5 preview release

January 29, 2009
* Public events optimized for a single calendar pool model

simplifies public events calendaring
filtering can be applied to all collections allowing for fine-grained control over subscriptions from within the user interfaces; no longer necessary to filter in the xslt of public client
administrative users tag events by topical area based on subscriptions within each calendar suite. The system then assigns appropriate categories to events.
administrative users can tag events with as many topical areas as appropriate
categories are maintained by superusers
categories can be set on all collections
adding a user to a calendar suite group will allow the user to administer the calendar suite
- Subscriptions greatly improved
all subscriptions are reimplimented as calendar aliases
subscriptions now appear in caldav clients such as Mozilla Lightning or Apple’s iCal
users can apply filters to aliases allowing for fine-grained control over subscriptions in the user client
subscriptions to external ical feeds available in public and personal clients
- Apache DS ldap directory ships with quickstart
used for user accounts, authentication, and the new CardDAV server
quickstart more closely resembles a production system
- CardDAV server first release
address book widget used in personal client queries attendees for meetings
- Timezone server in use
provides standardized timezone service
- CalDAV improvements
Support for draft 6 of CalDAV scheduling
Support for storing resources (e.g. files, attachments) within the folder hierarchy

3.4.1.1

June 3, 2008

Support for RFC-2445 x-properties
Inclusion of image URL for public events
Improvements to public event submission web client
Improvements to CalDAV and WebDAV
Improvements to dump/restore
Improvements to access control
Better support for driving public events client with categories
Fixes to scheduling - better support for COUNTER
Support deletion of non-empty calendars via CalDAV
Performance improvements to Lucene indexing
Bug fix for null parameters in x-props (thanks to Roberto Polli)

3.4.1

March 18, 2008

CalDAV: many improvements; greatly enhanced interoperability with Mozilla Lightning and Apple’s iCal; support for subscriptions to web calendars through the CalDAV server, allowing Bedework to expose user subscriptions to desktop clients; improved support for CalDAV filters
Addition of Public Events Submission web client (beta) which allows non-admin users to suggest public events. (configuration details)
Much better support for RSS and Javascript feeds including the addition of category filters and date ranges
Rudimentary interface for adding named CalDAV filters that can be used with the public web client providing powerful filtering features
Improvements to scheduling
Improvements to recurring event support
Improvements to freebusy
Improvemenst to locale support
Improvements to Lucene searching
Improvements to access control
Better handling of tasks
Better timezone handling
Numerous UI improvements including updated web template for mobile devices and an improved administrative interface
Bugfix to set all character encoding to utf-8 (thanks to Martin Blom)

3.4

September 14, 2007

Better standards support: A much more complete implementation of the calendaring standards RFC2445, RFC2446, RFC791 (CalDAV) and the CalDAV scheduling draft standard.
A reasonably complete implementation of iTIP scheduling, such as simple (non-recurring) iTIP scheduling, display of attendee FreeBusy information, sending invitations, update of attendee status, canceling meetings. There is some support of recurring meetings and modifications to instances partially works.
Portal support: A number of changes to make the user interface more portal friendly.
CalDAV: Changes/fixes have been implemented to improve interoperability with Apple’s iCal, and there is significant support now for CalDAV scheduling.
UI improvements to access control and recurring events.
Initial support for FREEBUSY URL and calendar subscription URL.
Apache Ant: Upgrade to 1.7 to make apt task available for further development.

3.3.1

April 25, 2007

Access fixes. Note this requires a change to the /public folder. Previously read + write-content was sufficient for administrative privileges. Now it must be read + write-content + bind (may also want unbind to allow deletions)
A number of bugfixes to CalDAV support.
Implemented some missing CalDAV features.
- attachments now work,
- copy/move/rename partially works.
- Freebusy information can be stored
- Tasks (todos)
- Search filters
Bug fixes for recurring events
Timezones shared correctly
Oracle now builds and deploys without alterations to generated schema.
Fixed up restore so that it can handle UWcal 2.3.2 data
12/24 mode works correctly
One-shot free and busy url works allow users to publicize their busy time.
Scheduling is now close to completion and largely usable. Some of the more esoteric features still require work, e.g. instances of recurring meetings, COUNTER is untested.
UI supports all access control features.
Import and export of calendars completed

3.3.1 preview release

February 23, 2007

CalDAV - Fixes to problems uncovered in the interoperability testing at CalConnect.
Recurring events - Fixes to some bugs, especially in the sharing of these events.
Timezones - Fixes to problems sharing events with 'private' timezones, such as those added via CalDAV or imported as ics.
Access control - Fixed some bugs in setting ACLs. The UI has been updated to enable all features of access control.
Scheduling - Implemented additional functionality. Scheduling is still incomplete but more features are exposed in 3.3.1 to allow further testing. We have successfully sent an invitation, posted a response, and observed the resulting event in the calendar. Scheduling support is "fragile" but progressing rapidly.
Bedework 3.3.1 is much more Oracle-friendly than previous versions. Based on work done by Julian Ball at Queens, and Chris Mann at Maryland, we have significantly overhauled the XML schema, with the intent of eliminating or at least drastically reducing the modifications Oracle users would have to make.

3.3

January 24, 2007

Java 1.5 and Tomcat 5.5 as implementation requirements
Lucene searching has been implemented for all clients
Categories have been reinstated
Many changes to CalDAV to better support various clients.
Significant progress supporting OpenConnector
Support for recipients and attendees
iCal import and export of multiple events / whole calendars
Improved timezone displays / support
Support for floating time values
Support for storing UTC time values
Recurring event support
Human readable text fields now stored with language information to facilitate internationalization
Scheduling (meeting requests, replies etc) are now mostly implemented
Significant improvements to the web user interfaces, XHTML user clients & dojo based widgets
Bug fixes (e.g. access control) and housekeeping (e.g. all tables given consistent names)

3.3 release candidate

December 15, 2006

A subset of the 3.3 release, above

3.3 preview release

November 22, 2006

Lucene searching added
Recurring and annotated event support rewritten
Added a String table to facilitate internationalization
Category support resuscitated, categories attached to calendars - implement changes to event categories
Java 5 language features to facilitate development
Fixes to access control and improved ui support
Added back-end support for todos
Support for scheduling operations
CalDAV improvements

3.2

August 15, 2006

SVN Restructuring complete
CalDAV improvements

3.1

August 1, 2006

Restructuring of system into multiple SVN projects
Working personal calendars released
Freebusy aggregator added
CalDAV server restructured to allow use as a proxy

3.1 release candidate 4

June 22, 2006

Restructuring of stylesheet directories to better support calendar suites
Initial release of jsr-168 compliant portlet for use within uPortal

3.1 release candidate 3

June 19, 2006

Further interface updates and bug fixes
Calendar Suites (departmental calendars) updated and highlighted

3.1 release candidate 2

June 12, 2006

Bug fixes
Upgrade to struts 1.2.9
Introduction of Calendar Suites:
- the Bedework system can now be defined as a collection of "calendar suites" which allows for the implementation of departmental calendars.

3.1 release candidate 1

May 19, 2006

Dump/restore and schema:
- Now zipped up with shell script for running stand-alone
Caldav fixes to bring up to draft 12
Prototype free/busy aggregator
Personal Client:
- sharing of events (as well as calendars and free-busy)
- bug fixes and interface updates
Admin and Public Clients:
- brought up-to-date with all changes

3.1pre

May 5, 2006

Personal Client:
- Preferences management in place
- Can select destination calendar when importing an event or adding an event reference
- Updates to access control
- Schema changes
- Graphical updates (also to public client)

3.1pre

April 21, 2006

Personal Client:
- Full calendar management in place
- Free/Busy display
- Basic sharing of calendars and free/busy

3.1pre

April 14, 2006

Personal Client: Fixed up personal client so basic functionality is restored. Client has been given a graphical overhaul.
Free/Busy: Preliminary work on free/busy
Lucene full text searching: Added classes to support Lucene indexing :sectnums: