Client Side Invitation Handling Notes
From Kolab Wiki
This page aims to describe the algorithm and approach to handling an invitation in iCal format in one of the Kolab clients.
Resolution Algorithm for the incidence to act upon
When an invitation is encountered by the email component, it is parsed, and the user is presented with action options. For usability reasons, a distinction is attempted between original invitations and updates. This is done heuristically, using the revision of the iCal incidence. Revision 0 indicates an original invitation, revisions > 0 are treated as updates. In the case of false positives (updates that are really invitations) all relevant actions are still available, but the user has to manually confirm them. The main options (for purposes of the resolution algorithm) are:
- delegate, make counterprosal, etc.
Let's look at each individually:
To accept an invitation, we check whether any of the available folders already contain an incidence with such a UID. If so, the revisions are compared, and if the existing incidence has a lower revision, an update is assumed. Processing then proceeds as in the section below. If the revision is higher, the update is discarded (FIXME: confirm this is the current Kontact implementation, FIXME: confirm this is the desired behavior). If no such incidence can be found, the user is asked for a target folder to store the incidence in. Cancel at this point cancels storing of the incidence, but leaves the invitation email in place.
If an update does not yet find an incidence with the same UID, it assumes to be an original invitation, and stores the incidence in a folder of the user's choice. If only one incidence with a matching UID is found, and its revision is lower than the update's, the changes from the update are applied. If its revision is higher FIXME: what happens here now?. In the case of more than one incidence with the update's UID, disambiguation is necessary. In order to find out which of the incidences is the one that the current user is likely to want to act upon, the attendee status of the current user in all of them is looked at. If in one of them the attendance status is already "accepted", it can be reasonably assumed that that is the one that needs to be updated. If more than one incidence version is eligible, the user is asked which incidence (in effect which folder) is to be acted upon.
Rejecting an event considers two main cases. If no such event can be found, the rejection simply results in an iTip email response to that effect. If a matching event is already in the calendar, it is deleted, but only if the current user's acceptance status is FIXME what?.