Introduce an API for managing event attendance (get / set)

[chibenwa]

Why?

Currently, on change of participation status on the frontend side (e.g. use clicks "accept" button), the backend receives an Email/set request containing an update object.

Example Request

{
   "using":[
      "urn:ietf:params:jmap:mail",
      "urn:ietf:params:jmap:core",
      "urn:apache:james:params:jmap:mail:shares"
   ],
   "methodCalls":[
      [
         "Email/set",
         {
            "accountId":"f0256b4c7ecc48687dd58dd5a3567c301672d6cb80607d5ead32d5d6c992cf3c",
            "update":{
               "627ebdc0-a8f2-11ef-82a5-9945e41adc32":{
                  "keywords/$accepted":true,
                  "keywords/$tentativelyaccepted":null,
                  "keywords/$rejected":null
               }
            }
         },
         "c0"
      ],
      [
         "Email/get",
         {
            "accountId":"f0256b4c7ecc48687dd58dd5a3567c301672d6cb80607d5ead32d5d6c992cf3c",
            "ids":[
               "627ebdc0-a8f2-11ef-82a5-9945e41adc32"
            ],
            "properties":[
               "keywords"
            ]
         },
         "c1"
      ]
   ]
}

In #1162, we are working toward a more general solution that allows us to receive participation status updates from the OpenPaas CalDAV server. This requires that we change our design a bit. As a first step, we need an API to manage event participation status and abstract it away from the frontend so that we support both:

• a standalone mode
• a mode connected to a DAV server.

How?

We want to introduce an EventAttendanceRepository interface allowing to modify participation status. In the tmail-backend/jmap/extensions-api project.

enum AttendanceStatus {
   Accepted, Tentative, Delegated, NeedsAction, Declined
} 

interface EventAttendanceRepository {
   Publisher<AttendanceStatus> getAttendanceStatus(Username username, MessageId messageId);
   
   Publisher<Void> setAttendanceStatus(Username username, MessageId messageId, AttendanceStatus attendanceStatus);
}

We need to write a StandaloneEventAttendanceRepository leveraging custom flags on the email to record attendance status. It must be interoperable with current frontend behaviour.

• No flag -> NeedsAction
• $accepted -> Accepted
• $tentativelyaccepted -> Tentative
• $rejected -> Declined
• $delegated -> Delegated

https://github.com/apache/james-project/blob/6e4dcf6e096431a64caefd944f9cc37c3c88473e/mailbox/api/src/main/java/org/apache/james/mailbox/MessageIdManager.java#L55-L57

DoD

Unit tests

[vttranlina]

$accepted -> Accepted
$tentativelyaccepted -> Tentative
$rejected -> Declined
$delegated -> Delegated

It would be better if the flag had a prefix, which would make it easier to distinguish from other flags, Eg. $calAttendanceAccepted

[chibenwa]

It would be better if the flag had a prefix, which would make it easier to distinguish from other flags, Eg. $calAttendanceAccepted

That's the current mobile app behaviour.

Let's keep it aligned for compatibility purposes.