BLUE-BAR: handle changes suggested by the participants

[chibenwa]

Description

Given Anne Sophie suggest changes to Benoit Event
And Benoit Opens the suggested changes
When Accepting Anne sophie proposal
Then the meeting is updated

Actual behavious

The event is rejected as we miss the REQUEST method

Expected behviour

(hoping that accepting the ICS and forwarding it to OpenPaaS is enough)

Accepting METHOD:COUNTER for CalendarEvent/accept ?

Related materials

meeting.ics.txt

mail.eml.txt

Definition of done

VERIFY FIRST THAT ACCEPTING the ICS is ENOUGH - Rogue deploy of a patched image onto imap.linagora.com to this end is acceptable: Receive a counter, accept it, and see if the event is correctly updated....

Then simply commit the changes and open a PR... (no integration test needed for cross product integration with OpenPaaS).

[HoussemNasri]

According to the specs, when the organizer receives a COUNTER event schedule, they can accept or reject (no maybe)

• On rejection, it is quite easy to handle, we just send DECLINECOUNTER ics to the attendee that countered our event schedule.
• On acceptence, we need to reschedule the event, that is send the same ICS (same UUID) to all attendees with the new schedule/changes, that require its own ticket IMO.

The forwarding of the ICS is already possible through some mailet chaining, see calendarEventReply.adoc. However, I can't tell if it will work or not. It looks like OpenPaas is treating james:events as a "fallback" exchange, not sure what that means.

[chibenwa]

On acceptence, we need to reschedule the event, that is send the same ICS (same UUID) to all attendees with the new schedule/changes, that require its own ticket IMO.

@HoussemNasri using your Linagora account could you document the curl commends for doing so using CalDav?

With that and a bit of Sabre impersonation we could have a JMAP method doing just that: accept counters

[HoussemNasri]

Context

Rescheduling events is automatically detected by the CalDAV server when it receives a VEVENT identified by a UUID that already exists on the server but has a different DTSTAMP (indicating when the event was created or last updated).

On the TMail side, the event organizer receives an email containing the COUNTER schedule with the DTSTAMP property correctly set and the updated counter schedule. As the event organizer, you can either accept or reject this counter schedule.

• Accepting the counter schedule initiates the Rescheduling Events with CalDav workflow.
• Rejecting the counter schedule sends a DECLINECOUNTER response to the user who proposed the change (findout: can we delegate this job to the CalDav server)

---

Workflow: Rescheduling Events with CalDav

Input: The ICS file received in the email containing the counter schedule.

A blog post by atmail mentions using calendars/{{USER_EMAIL}}/ as a base URL to query all calendars for a user. However, OpenPaas seems not to support such queries directly (though this assumption might need verification). For now, we fetch all calendars first and run VEVENT-finding queries on each one.

---

Step 1: Query all calendars accessible to the user

Output:

• List of CALENDAR_ID (e.g., 621637f128549d002582c9b6)

Example response:

<d:response>
    <d:href>/calendars/66e95872cf2c37001f0d2a09 <!-- CALENDAR_ID -->
...

Command:

curl --user 'email:password' \
     -s -X PROPFIND \
     -H "Content-Type: application/xml" \
     -H "Depth: infinity" \
     -sD /dev/stderr https://dav.linagora.com:443/calendars | xmllint -format -

Step 2: Query each calendar to find the VEVENT by UUID

Inputs:

• CALENDAR_ID (e.g., 621637f128549d002582c9b6)
• VEVENT_UUID (e.g., 2074e9b9-1a1b-4186-8a01-5cec86d06d6f)

Output:

• ICS_PATH_ON_SERVER (e.g., 66e95872cf2c37001f0d2a09/66e95872cf2c37001f0d2a09/sabredav-a9d8ac5e-deeb-4a71-9ee5-17bea30ddcc8.ics)

Example response:

<d:response>
    <d:href>/calendars/66e95872cf2c37001f0d2a09/66e95872cf2c37001f0d2a09/sabredav-a9d8ac5e-deeb-4a71-9ee5-17bea30ddcc8.ics <!-- ICS_PATH_ON_SERVER -->
    <d:propstat>
        <d:prop>
        ...
    </d:propstat>
</d:response>

Command

curl --user 'email:password' \
     -sD /dev/stderr \
     -X REPORT \
     -H "Content-Type: application/xml" \
     -H "Depth: 1" \
     --data '<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
               <D:prop xmlns:D="DAV:">
                 <D:getetag/>
                 <C:calendar-data/>
               </D:prop>
               <C:filter>
                 <C:comp-filter name="VCALENDAR">
                   <C:comp-filter name="VEVENT">
                     <C:prop-filter name="UID">
                       <C:text-match collation="i;octet">{{VEVENT_UUID}}</C:text-match>
                     </C:prop-filter>
                   </C:comp-filter>
                 </C:comp-filter>
               </C:filter>
             </C:calendar-query>' \
     https://dav.linagora.com:443/calendars/{{CALENDAR_ID}}/{{CALENDAR_ID}} | xmllint -format -

Step 3: Update the ICS file on the server with the counter schedule

Input:

• ICS_PATH_ON_SERVER

Once the ICS file is located, update it with the counter schedule using a PUT request. Assuming the counter schedule is stored locally as counter_event.ics, execute:

Command:

curl -X PUT https://dav.linagora.com:443/calendars/{{ICS_PATH_ON_SERVER}} \
     --user 'email:password' \
     --header "Content-Type: text/calendar; charset=utf-8" \
     --data-binary @counter_event.ics

References

[chibenwa]

Step 1: Query all calendars accessible to the user - HOW do we get the one interesting us?

IMO let's query OpenPaas to get the user id then we can use /calendars/66e95872cf2c37001f0d2a09 with 66e95872cf2c37001f0d2a09 being the user ID

Isn't it the best way to find the principal?

Step 2: We need to account for one principal to have several calendars

Is

curl --user 'email:password' \
     -sD /dev/stderr \
     -X REPORT \
     -H "Content-Type: application/xml" \
     -H "Depth: 1" \
     --data '<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
               <D:prop xmlns:D="DAV:">
                 <D:getetag/>
                 <C:calendar-data/>
               </D:prop>
               <C:filter>
                 <C:comp-filter name="VCALENDAR">
                   <C:comp-filter name="VEVENT">
                     <C:prop-filter name="UID">
                       <C:text-match collation="i;octet">{{VEVENT_UUID}}</C:text-match>
                     </C:prop-filter>
                   </C:comp-filter>
                 </C:comp-filter>
               </C:filter>
             </C:calendar-query>' \
     https://dav.linagora.com:443/calendars/{{CALENDAR_ID}} | xmllint -format -

okay?

[chibenwa]

Please :

• Refine the DAV commands based on my feedback
• Do the same for Reflect calendar updates into twake mail #1162