Cyrus CalDAV Scheduling Flowchart

caldav_put() - create/modify via HTTP PUT on a resource or POST (add-member) on a calendar

1. Check if the new resource is a scheduling resource (contains ORGANIZER property). If not, skip to step 4.
2. Check for (and load) any existing resource.
3. Check if the authenticated user matches ORGANIZER:
   • If yes:
     • If only voter (VPOLL) responses changed, goto sched_pollstatus().
     • Otherwise, goto sched_request().
   • Otherwise, goto sched_reply().
4. Store the new/modified resource.

caldav_delete_sched() - remove via HTTP DELETE on a resource

1. Check if the existing resource is a scheduling resource (has Schedule-Tag). If not, we are done.
2. Load the existing resource.
3. Check if the authenticated user matches ORGANIZER. If yes, goto sched_request(), otherwise goto sched_reply().

caldav_post() - busytime query via HTTP POST on Scheduling Outbox

1. Check the ACL on the owner's Scheduling Outbox. If the authenticated user doesn't have the DACL_SCHEDFB right, fail.
2. sched_busytime_query().

sched_pollstatus - perform a voter response update

sched_request() - perform an organizer request / attendee status update

1. Check the ACL on the owner's Scheduling Outbox. If the authenticated user doesn't have the DACL_INVITE right, fail.
2. If the request includes a resource, then set METHOD:REQUEST, otherwise set METHOD:CANCEL.
3. Create an iTIP message template, copying over any CALSCALE property and VTIMEZONE components.
4. If not an attendee status update and the existing resource is a scheduling resource: Foreach component in the existing resource, add it and its SEQUENCE to our hash table keyed by RECURRENCE-ID (for comparison against new/modified resource).
5. Create a hash table of attendees. This will hold attendee-specific iTIP messages.
6. Foreach component in the new/modified resource:
1. Lookup (by RECURRENCE-ID) and remove the component from the hash table of existing components.
2. If the component exists compare all of DTSTART, DTEND, DURATION, RRULE, RDATE, EXDATE to those of the new component.
3. If the component is new or changed, then process_attendees().
7. Foreach remaining component in the hash table of existing components do sched_cancel().
8. Foreach iTIP message in our hash table of ATTENDEES, sched_deliver() the iTIP message.
9. Foreach component in the new/modified resource update the SCHEDULE-STATUS of each ATTENDEE.

process_attendees() - create a suitable iTIP request message for each attendee

1. Foreach ATTENDEE in the component, remove the SCHEDULE-STATUS parameter, and set PROPSTAT=NEEDS-ACTION if required.
2. Make a copy of the component and clean_component().
3. Foreach ATTENDEE in the cleaned component:
1. Check the CalDAV Scheduling parameters. If SCHEDULE-AGENT != SERVER, skip to the next attendee.
2. Lookup attendee in our hash table.
3. If it doesn't exist, create a clone of our iTIP template and insert it into our hash table of attendees.
4. Add the component to the attendee's iTIP message.
5. Add the component “number” to our mask of new components appearing in the attendee's iTIP message.
4. If the component is not the "master", foreach attendee do sched_exclude().

sched_exclude() - exclude an attendee from a recurrence instance

1. If the component did not appear in the attendee's iTIP message, add an EXDATE property (based on the RECURRENCE-ID of the component) to the master component of the attendee's iTIP message.

sched_cancel() - cancel an organizer event/task

1. Set STATUS:CANCELLED on the component.
2. process_attendees().

sched_reply() - perform an attendee reply

1. Check the CalDAV Scheduling parameters on ORGANIZER. If SCHEDULE-AGENT != SERVER, we are done.
2. Check the ACL on the owner's Scheduling Outbox. If the authenticated user doesn't have the DACL_REPLY right, fail.
3. Create a new iTIP (METHOD:REPLY) message, copying over any CALSCALE property and VTIMEZONE components.
4. Foreach component in the existing resource:
1. trim_attendees().
2. Add the trimmed component and the attendee's PARTSTAT to our hash table keyed by RECURRENCE-ID (for comparison against new/modified resource).
5. Foreach component in the new/modified resource:
1. trim_attendees().
2. Lookup (by RECURRENCE-ID) and remove the component from the hash table of existing components.
3. If the component exists:
1. If component is VPOLL, add voter responses to REPLY via sched_vpoll_reply().
2. Otherwise, compare the PARTSTAT of the ATTENDEE to that of the new component.
4. If the component is new or the PARTSTAT has changed:
1. clean_component().
2. Add the component to our iTIP message.
3. Add the component “number” to our mask of new components appearing in our iTIP message.
6. Foreach remaining component in the hash table of existing components do sched_decline().
7. sched_deliver() our iTIP message.
8. Foreach component in the new/modified resource that appeared in our iTIP message, update the SCHEDULE-STATUS of the ORGANIZER.

trim_attendees() - remove all attendees other than the one replying

1. Clone the component and remove all ATTENDEE properties other than the one corresponding to the owner of the calendar.
2. Return the ATTENDEE property of owner, his/her PARTSTAT parameter, and the RECURRENCE-ID of the component.

sched_vpoll_reply() - add voter responses to VPOLL reply

sched_decline() - decline a recurrence instance for an attendee

1. Set PARTSTAT of ATTENDEE to DECLINED.
2. clean_component().
3. Add the component to our iTIP message.

clean_component() - sanitize a component for use in an iTIP message

1. Update DTSTAMP.
2. Remove any VALARM components.
3. For a reply/decline only, remove scheduling parameters from ORGANIZER.

sched_deliver() - deliver an iTIP message to a recipient

1. Lookup the recipient.
2. If local to our server goto sched_deliver_local(), otherwise goto sched_deliver_remote().

sched_deliver_local() - deliver an iTIP message to a local user

1. Check the ACL on the owner's Scheduling Inbox. If the sender doesn't have the proper right (DACL_INVITE for request/cancel, DACL_REPLY for reply), fail.
2. Search the recipient's calendars for a resource having the specified UID.
3. If the resource doesn't exist:
1. If the iTIP method is REPLY, fail (we are done).
2. If the iTIP method is CANCEL, ignore it (we are done).
3. Otherwise, create a new (empty) attendee object and target the recipient's Default calendar.
4. Otherwise, load the existing resource.
5. Update the new/existing resource:
1. If the iTIP method is CANCEL, set STATUS:CANCELLED on all existing components.
2. If the iTIP method is REPLY, do deliver_merge_reply().
3. If the iTIP method is REQUEST, do deliver_merge_request().
4. If the iTIP method is POLLSTATUS, do deliver_merge_pollstatus().
6. Store the new/updated resource in the recipient's target calendar.
7. Record the delivery status (SCHEDULE-STATUS).
8. If the iTIP message is something other than just a PARTSTAT update from an attendee, store the iTIP message as a new resource in the recipient's Inbox.
9. If the iTIP method is REPLY, send an update other attendees via sched_pollstatus() (VPOLL only) or sched_request().

deliver_merge_reply() - update an organizer resource with an attendee reply

1. Foreach component in the existing resource, add it to our hash table keyed by RECURRENCE-ID (for comparison against iTIP message).
2. Foreach component in the iTIP message:
1. Lookup (by RECURRENCE-ID) the component from the hash table of existing components.
2. If the component doesn't exist (new recurrence overridden by ATTENDEE) create a new recurring component:
1. Clone the existing master component.
2. Remove the RRULE property.
3. Add the RECURRENCE-ID from the iTIP message.
4. Replace the DTSTART, DTEND, SEQUENCE properties with those from the iTIP message.
5. Add the new component to our existing resource.
3. Get the sending ATTENDEE from the iTIP message.
4. Find the matching ATTENDEE in the existing component.
5. If not found (ATTENDEE added themselves to this recurrence), add new ATTENDEE to the component.
6. Set the ATTENDEE PARTSTAT, RSVP, and SCHEDULE-STATUS parameters in the existing component.
7. If the component is VPOLL, update the voter responses in the existing component via deliver_merge_vpoll_reply().
3. Return the sending ATTENDEE.

deliver_merge_vpoll_reply() - update an organizer resource with voter responses

1. Foreach sub-component in the existing resource, replace any voter response(s) with those from the reply.

deliver_merge_request() - create/update an attendee resource with an organizer request

1. Foreach VTIMEZONE component in the existing resource, add it to our hash table keyed by TZID (for comparison against iTIP message).
2. Foreach VTIMEZONE component in the iTIP message:
1. Lookup (by TZID) the VTIMEZONE component from the hash table of existing components.
2. If the component exists, remove it from the existing object.
3. Add the VTIMEZONE from the iTIP message to our existing object.
3. Foreach component in the existing resource, add it to our hash table keyed by RECURRENCE-ID (for comparison against iTIP message).
4. Foreach component in the iTIP message:
1. Clone a new component from the iTIP component.
2. Lookup (by RECURRENCE-ID) the component from the hash table of existing components.
3. If the component exists:
1. Compare the SEQUENCE of the new component to the existing component to see if it has changed.
2. Copy any COMPLETED, PERCENT-COMPLETE, or TRANSP properties from the existing component to the new component.
3. Copy any ORGANIZER SCHEDULE-STATUS parameter from the existing component to the new component.
4. Remove the existing component from the existing object.
4. Add the new component to the existing object.

deliver_merge_pollstatus() - update voter responses on a voter resource

1. Foreach sub-component in the existing resource, add it to our hash table keyed by POLL-ITEM-ID (for comparison against iTIP message). The sub-component entry includes a hash table of VOTERs.
2. Foreach sub-component in the iTIP message:
1. Lookup (by POLL-ITEM-ID) the sub-component from the hash table of existing sub-components.
2. If the component exists, foreach VOTER in the sub-component in the iTIP message:
   1. Lookup VOTER in the hash table of existing sub-component.
   2. Add/update VOTER response.

sched_deliver_remote() - deliver an iTIP message to a remote user

1. If the recipient is local to our Murder, goto isched_send(), otherwise goto imip_send().
2. Retrieve status of iTIP message delivery.

isched_send() - deliver an iTIP message to a remote user via iSchedule (HTTP)

imip_send() - deliver an iTIP message to a remote user via iMIP (SMTP)

sched_busytime_query() - perform a busytime query

busytime_query_local() - perform a busytime query on a local user

busytime_query_remote() - perform a busytime query on a remote user