This release should come out soon after 3.4.1.1 and will incorporate a number of changes which should be relatively easy to deploy before we do the major UI overhaul.

Summary of changes

Data update from 3.0 will not work

As a result of simplifying the collection schema a fix for 3.0 data will not correctly set the calendar type field. Also duplicate event names (a bug in 3.0) will not be corrected. The best approach, restore to 3.4.1.1 with the fix 3.0 option set, dump and restore the fixed data to 3.5.

Timezones

In 3.5 we no longer have private timezones. All timezones within the system come from the set of standard system timezones. This facilitates the move towards a standard timezone service. This release incorporates a timezones server which will ease the process of updating timezone information. See wiki:Timezones

Reimplement subscriptions as calendar alias

In Bedework up to 3.4.1.1 subscriptions are different and separate from the collection hierarchy. In 3.5 a number of new types of collection object have been defined. One of these is the "alias" which takes the place of the subscription to an internal collection.

This change apart from simplifying the ui, makes subscribed calendars visible via CalDAV. Clients such as Apple's iCal don't currently allow subscriptions to CalDAV shared calendars (though they do allow subscriptions to web based calendars). In version 3.5 these subscription will appear in ical along with your own collections.

This allows us to have a view of events which is consistent across all clients.

External calendar subscriptions

In addition to the alias we now have the external subscription to an ics feed, for example, eventful,com or google. This allows the user to specify a url and optionally a userid and password (which will be stored encrypted). The calendar will be refreshed periodically and appears as part of the users calendar hierarchy. Again, this external subscription will be visible via caldav clients.

Filters

Allow basic filtering on calendars. In addition to the alias change we should allow filtering to be applied to all calendars. This would allow us to subscribe to "Movies" say and then filter for a particular sub-category. Filters will be expressed as a sql query so should be efficient.

Annotations

Use annotations to automatically create BwEventProxy and possibly dump and restore code. Other possible uses are icalendar transformations and wrapper classes.

Storing resources in folders

Support is in place for storing resources (e.g. files) within the folder hierarchy. This allows us to fully support the approach outlined in the CalDAV rfc and will allow shared attachments, the creation of image repositories etc. The schema changes involved here are the addition of two new tables, one to store the resource information and one to store the resource content. Content has to be fetched explicitly.

Images, files etc will be availabel via a url and access restrictions are imposed.

Import of ics

For personal calendars we can take a relaxed approach to import - add uid if missing etc. For public events administration we need to add to the ui to allow import to be used as a data validation service - i.e. don't import just validate, as well as importing. We should apply the same validation to bulk import as we do to forms entry. Better reporting of errors is also needed.

Data feeds

Read-only ics data feeds supported Read-only json data feeds supported

=== Move to jquery from dojo

Root user list.

Move specification of root users out of the authuser stuff and instead have a comma separated list of auth users in the system parameters.

Dump/restore will create that list when upgrading.

At the same time remove the alert user stuff, It was never used.

---

Build process changes

A significant number of changes to the build process - hopefully to make it clearer and easier to understand.

• Properties file is now exclusively build time properties and is no longer included in the war file.
• Options file is exclusively run time properties.
• New build script bw which allows for multiple configurations
• Libraries now downloaded at build and deploy time from bedework.org

Properties and options tidied up

The properties file is now exclusively build time properties and is no longer included in the war file while the options file is exclusively run time properties. Any properties needed at both run time and build time will be copied out of the run time options by the build process.

Following properties were moved into the options:

• org.bedework.app.X.nogroupallowed
• org.bedework.app.X.publicadmin
• org.bedework.app.X.guestmode
• sysintfimpl (caldav)
• org.bedework.global.system.name --> globals.systemName
• org.bedework.app.X.run.as.user --> runAsUser
• org.bedework.app.CalAdmin?.admingroupsidprefix=agrp_

Removed the org.bedework.app.X.root properties - no longer needed.

New build script

The bw script in the quickstart directory is used to build and deploy. It makes use of a number of configurations stored in the bedework/config directory. The directory bwbuild can be copied into your home directory and allows for a number of configurations to be saved and selected by the bw -bwc parameter.

---

Schema changes

Allow language/locale settings

alter table BW_SETTINGS add column bwlocales varchar(1000)

Calendar alias

alter table BW_CALENDARS add column bw_alias_uri varchar(500);
alter table BW_CALENDARS add column display char(1) default 'T';
alter table BW_CALENDARS add column affects_free_busy char(1) default 'T';
alter table BW_CALENDARS add column unremoveable char(1) default 'F';
alter table BW_CALENDARS add column bwrefreshseconds integer default 0;
alter table BW_CALENDARS add column bwlastrefresh varchar(16);
alter table BW_CALENDARS add column bwlastetag varchar(256);

update BW_CALENDARS set BWREFRESHSECONDS=0

Remove Calendar collection flag

alter table BW_CALENDARS drop column calendar_collection;

Root user list

alter table bw_settings add column bwroot_users varchar(500)
update bw_settings set bwroot_users='root,caladmin'
update BW_AUTH set USERTYPE=192 where USERTYPE>192

Data conversion from earler versions to 3.5

The dump/restore process will do the usual job of converting from earler versions. For 3.5 the changes are more significant than before and are detailed here.

Super or root users

Formerly super users were flagged as such in the authorised user table. This table is not needed and it's functions have been replaced (lrgely).

Super users are now specified bya simple comma separated list stored as a property in the system settings. A super user can be defined simply by adding their account to the list. This avoids some of the problems of bringing up bedework in an authentication domain which does not have any of the quickstart super users defined.

Use the administration client system settings page to chnage the list.

Subscriptions

Subscriptions have changed significantly from being a separate entity to an alias store in the collection hierarchy. The data conversion drops any subscription into the users own collections and adds a single entry to their default view which is their calendar home. Early versions of bedework had subscriptions to each calendar collection a user created. This was changed to a single subscription to the calendar home. Some users may see a difference, most will not. Those who do are probably getting a better experience than previously.

Subscriptions to collections the current user does not own are turned into the new alias format added at the calendar home level.

Administrative group accounts (those that start with "agrp_") additionally have their subscriptions made world readable as these are used to create the set of view used by the public clients.