[Kolab-devel] [issue4554] Automatic invitation handling of accounts with multiple calendar folders when partial data may be outdated

Gunnar Wrobel issues at kolab.org
Sun Sep 19 23:44:53 CEST 2010


New submission from Gunnar Wrobel <wrobel at kolabsys.com>:

Another spin off from the discussion in kolab/issue4481 (Automatically trigger a
resource when booking in case its free/busy information is too old).

Thomas and I discussed the question of what happens in automatic invitation
handling in case the invited account has not only one but several calendar accounts.

Let's consider a case of an account "demo" with two calendar folders. The
default calendar folder "Calendar" is accessible to the default calendar user on
the system. The second calendar is called "Meetings" and only accessible to the
CEO of the company owning the server.

Assume the "Meetings" folder has a recurring event that indicates a meeting on
monday morning. The event was created two years ago but is still valid. The
folder that contains this event was triggered the last time when the event was
created: two years ago.

The "Calendar" folder on the other hand holds current data and has been
triggered recently. In that case the accumulated free/busy data for the account
will span the full two years with one short period with outdated events at the
beginning of the period, a long apparently available stretch in the middle, and
a period with real events at the end.

I actually tested this with a Kolab 2.2.4 server and the result looks indeed
like described above:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//kolab.org//NONSGML Kolab Server 2//EN
METHOD:PUBLISH
BEGIN:VFREEBUSY
ORGANIZER;cn=r r:MAILTO:r at ec2-75-101-183-93.compute-1.amazonaws.com
DTSTAMP:20080919T212630Z
URL:http://ec2-75-101-183-93.compute-1.amazonaws.com/freebusy/r@ec2-75-101-
 183-93.compute-1.amazonaws.com.xfb
DTSTART:20080918T220000Z
DTEND:20101117T230000Z
FREEBUSY:20080919T040000Z/20080919T050000Z
FREEBUSY:20100920T040000Z/20100920T050000Z
END:VFREEBUSY
END:VCALENDAR

This is pretty bad. Maybe not so much for the free/busy data itself but from the
viewpoint of resource management. The result shown above is not acceptable for
reliable automatic invitation handling at all.

Fixing this should however not be too hard. Currently we merge the partial
free/busy lists by creating a joined list that starts at the earliest start date
and ends at the latest end date of the partial lists.

Instead the combined list needs to contain the smallest overlapping time period
of all the partial free/busy lists. This is the only time span where we know we
have reliable data. So this is the only time span we should report to the
outside (or at least to the side of the automatic invitation handling).

If there is no such overlapping time span than the system should report a 404
error clearly indicating the actual problem.

I'm aware that this might happen quite easily if an account combines several
calendar folders. But displaying reliable data is far better than showing
incorrect data. And the problem can be circumvented by setting a larger
FREEBUSYFUTURE setting or by running the regenerate script from time to time.

The fix for kolab/issue4481 (Automatically trigger a resource when booking in
case its free/busy information is too old) would then need to be extended so
that the invitation handling tries to trigger *all* calendar folders it sees on
the invited account in order to try to resolve the situation and get up-to-date
free/busy data.

So admins could either ensure that all folders allow access for the system
calendar user or they react to users bugging them about outdated free/busy data.

----------
assignedto: wrobel
keyword: freebusy, server
messages: 26445
nosy: bernhard, cwickert, martin, thomas, wilde, wrobel
priority: bug
status: unread
title: Automatic invitation handling of accounts with multiple calendar folders when partial data may be outdated

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4554>
______________________________________




More information about the devel mailing list