Package org.exoplatform.caldav.service

Class CaldavRemoteEventCopyPlugin

java.lang.Object
org.exoplatform.caldav.service.CaldavRemoteEventCopyPlugin
All Implemented Interfaces:
org.exoplatform.agenda.plugin.RemoteEventCopyPlugin
@Service public class CaldavRemoteEventCopyPlugin extends Object implements org.exoplatform.agenda.plugin.RemoteEventCopyPlugin
Tells agenda whether this add-on is going to write a user's copy of a meeting into their connected calendar account (EXO-90247).

Why agenda has to ask rather than work it out

Agenda leaves the event.ics file out of an invitation mail when the recipient is going to hold a synced copy of the same meeting, because the two carry different UIDs and no client can reconcile them. Until this plugin existed, agenda answered that from the recipient's own settings — a guess at a decision this add-on owns, and the two drifted apart in both directions at once:

  • CaldavPendingInvitationService seeds copies server-side behind CaldavCopyConsent, which reads the account's push switch and not agenda's automaticPushEvents. A user who had turned that global switch off was predicted to hold no copy, so the file was attached — and the seeding pass wrote the copy anyway. The meeting twice, which is the very symptom this task was opened for.
  • Conversely, when this add-on gained a reason of its own to decline a copy for a particular invitee, agenda knew nothing of it and still suppressed the file. The meeting nowhere: no copy, no attachment, no calendar entry anywhere. That is what the first attempt at this task shipped, and what the rig measured.

Aligning the two predicates by hand would have closed today's gap and left the mechanism that produced it — two repositories each modelling the other — intact for the next rule either side adds. So the answer moves to the only party that can give it, and agenda stops modelling this add-on at all.

What it reads, and what it deliberately does not

The same two questions the write paths ask, through the same beans, so there is one reading and not a third: does this user take copies at all (CaldavCopyConsent), and may this meeting be copied at all (CaldavCopyPolicy).

It does not go on to ask whether the account names a usable destination collection, or whether the server is reachable. Those need a round trip or a load this answer cannot afford on the notification path, and the cost of not asking is bounded and already accepted: a user whose account is connected but whose server has been unreachable loses the attachment, as they did before this plugin existed — and they are already receiving none of their meetings, which is a different fault with a different fix.

  • Constructor Details

    • CaldavRemoteEventCopyPlugin

      public CaldavRemoteEventCopyPlugin()

  • Method Details

    • writesCopyOf

      public boolean writesCopyOf(org.exoplatform.agenda.model.Event event, long recipientIdentityId)
      Whether a copy of this meeting is going to be written into this recipient's connected CalDAV account.

      Answers false on anything it cannot establish, which is the direction the interface requires: a wrong "no" costs the recipient a redundant file, a wrong "yes" costs them the invitation altogether.

      Specified by:
      writesCopyOf in interface org.exoplatform.agenda.plugin.RemoteEventCopyPlugin
      Parameters:
      event - the meeting, as agenda holds it
      recipientIdentityId - organization identity id of the recipient, 0 for a guest
      Returns:
      true only when this add-on will write that recipient a copy